How to debug selectapdu from android nfc emulator to arduino with pn532? - flutter
i'm trying to use the example android_hce from arduino with nfc_emulator with flutter. But the problem is i always recieve apdu response 00 00 and couldnt ffind it in the apdu response list. What does that mean? Using AID 0xF0, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 on arduino and F0010203040506 on android still cant manage to do it
Related
16-bit addresses register in i2c stm32
i want to write in AT24C512 with stm32f103c8 i send my code. HAL_I2C_Mem_Write(&hi2c1, 0XA0, 0X11FA,I2C_MEMADD_SIZE_16BIT , &write_data, 1, 100); For example, I want to put the value of write_data on 0x11FA, and I specify the memory address as 16 bits, but it is always sent as 8 bits, and AT24C512 seems to receive only the first byte of 0x11FA It means AT24C512 receive just 0x11 and its not difference if i set mt address register to 0x1167 0x11FF 0x11A0 all these address is same for AT24C512. what should I do? Because I used the module, I am sure the hardware have no problem i want to write and read correctly in AT24C512 with stm32f103c8.
AES enc/dec gives on different platforms different outputs for the first 16 bytes
I have a really strange behaviour about encryption and decryption with AES CBC. I use a python script to encrypt a block of data and would like to decrypt it on a microcontroller (TI C2000) and somehow it works, but the first 16 bytes of a 128 byte block are always different on the C2000 and the Python Script and I really don't know how this is possible. Especially it is strange, since the input data in the encryption routine is exactly as expected, since my first tought was, that it must be incorrect input data, but that is not the case.
The block I encrypt/decrypt looks like this:
key[16] = {0x2b, 0x7e, 0x15, 0x16, 0x28, 0xae, 0xd2, 0xa6,
0xab, 0xf7, 0x15, 0x88, 0x09, 0xcf, 0x4f, 0x3c}
iv[16] = {0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F}
data_unencrypted[128] = {0x00,0x00,0x1b,0x00,0x01,0x00,0x00,0x00,0x02,0x00,0x76,0x58,0x08,
0x00,0x10,0x00,0xf0,0xff,0x00,0x00,0x46,0x55,0x08,0x00,0x7f,0x58,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x63,
0x08,0x00,0x30,0xa1,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}
data_encrypted_python[128] = {0x2f,0xf2,0x20,0x85,0x2d,0xcd,0xb7,0x5e,0xfe,0x2b,0x90,0xe7,0x66,
0x3e,0xbb,0x3e,0xfa,0x15,0xf1,0xca,0x3e,0xc4,0x92,0x33,0x1a,0xc1,0xea,0x36,0x33,0xc5,0xeb,0xd4,0x33,0x5f,
0xcd,0x06,0x74,0xd4,0x85,0x79,0xed,0xf8,0xdc,0x5e,0x45,0x3d,0x74,0x29,0x63,0x69,0x77,0xc9,0x8b,0xdd,0x09,
0x8b,0xb4,0x2c,0xd7,0xf9,0xe9,0x94,0x1b,0x5d,0x20,0xa4,0x01,0xa7,0x91,0x67,0x24,0xa3,0x78,0xf7,0x72,0x6e,
0xbd,0xd3,0x37,0x27,0x13,0xcd,0x44,0x40,0x35,0x49,0x2d,0xf7,0xdd,0x58,0x35,0xe9,0x1b,0x1d,0x1f,0x97,0xe0,
0xe4,0xc4,0x89,0x0c,0x88,0x46,0x61,0x47,0xbc,0x87,0x3a,0xf5,0x50,0x9b,0xb0,0x4b,0xd9,0x8e,0x05,0x31,0x7c,
0x2a,0xd3,0xb5,0x3b,0xdd,0xa1,0x67,0xc3,0x60,0x39}
--> decrypt in python gives the same as the unencrypted, original data from above.
data_decrypted_c2000[128] = {0x1c,0xc4,0x2b,0xb7,0xd2,0x8d,0x18,0x31,0xe8,0x96,0x30,0x70,0xb5,
0x6a,0xad,0xd3,0xf0,0xff,0x00,0x00,0x46,0x55,0x08,0x00,0x7f,0x58,0x08,0x00,0x00,0x00,0x00,0x00,0x00,0x63,
0x08,0x00,0x30,0xa1,0x00,0x00,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff}
--> Note, that only the first 16 bytes are false.
How is this possible? Is it even possible without input data corruption?
Yes, it is possible, since CBC uses the previous ciphertext as "vector" for the current block it is trying to decrypt. If a vector is incorrect then the resulting plaintext is also incorrect. However, since the next block only depends on the ciphertext that plaintext error doesn't propagate during decryption. What is likely happening is that the C2000 uses the wrong - seemingly random - IV value. Like all other vectors this is XOR'ed with the result of the block cipher decrypt resulting in an also randomized plaintext block. If the next plaintext block would have any (small) error then the ciphertext block could have been corrupted, but that's obviously not the case here. EDIT: After a careful look, I find that the C2000 actually produces the result you would expect given the currently specified IV. That means that the Python IV handling is incorrect, even though it is consistent in both the encryption & decryption functionality.
Sending data over UART from a buffer filled by DMA
I have an ADC set up with DMA to fill a buffer in circular mode. I've verified with the debugger that this buffer is being filled with the expected data.
I am using a FreeRTOS task to send this data over UART based on the interrupts provided by the DMA functionality. When the buffer is half full, I send the first half; when the buffer is full, I send the second half.
I am using a Nucleo L476RG.
Here is my code:
#include "ADC.hpp"
#include <string.h>
#include "FreeRTOS.h"
#include "semphr.h"
#include "task.h"
#include "main.h"
#include "utils/print.hpp"
#include "stm32l4xx_hal.h"
extern ADC_HandleTypeDef hadc3;
extern UART_HandleTypeDef huart2;
extern volatile SemaphoreHandle_t print_lock;
namespace ADC
{
volatile SemaphoreHandle_t adc_lock;
volatile uint16_t adc_buf[ADC_BUF_SIZE];
volatile uint8_t buf[] = "abcdefg\r\n";
void task(void *arg)
{
adc_lock = xSemaphoreCreateBinary();
HAL_ADC_Start_DMA(&hadc3, (uint32_t *)adc_buf, ADC_BUF_SIZE);
HAL_StatusTypeDef result;
uint16_t offset = ADC_BUF_SIZE >> 1;
while (1)
{
xSemaphoreTake(adc_lock, HAL_MAX_DELAY);
offset = (offset + (ADC_BUF_SIZE >> 1)) % ADC_BUF_SIZE;
xSemaphoreTake(print_lock, HAL_MAX_DELAY);
while ((result = HAL_UART_Transmit(&huart2, (uint8_t *)adc_buf+offset*2, ADC_BUF_SIZE, HAL_MAX_DELAY)) == HAL_BUSY) {}
xSemaphoreGive(print_lock);
}
vTaskDelete(nullptr);
}
} // namespace ADC
void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef *hadc)
{
HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_SET);
xSemaphoreGiveFromISR(ADC::adc_lock, nullptr);
}
void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef *hadc)
{
HAL_GPIO_WritePin(LD2_GPIO_Port, LD2_Pin, GPIO_PIN_RESET);
xSemaphoreGiveFromISR(ADC::adc_lock, nullptr);
}
Here is a screenshot from the debugger showing correct data in adc_buf
When looking at the received data using screen /dev/ttyACM0 115200, then converting to hex using vscode, this is what is received. I have already verified that the baudrate is correct.
I've tried adding a buffer with a long string message and sending that over and over, and it is sent and received correctly. Only data from the DMA buffer is being sent as 0xFD rather than the correct bytes. All other data is sent and received correctly.
Here are the settings for the UART and the ADC/DMA.
When looking at the received data using screen /dev/ttyACM0 115200, then converting to hex using vscode, this is what is received. Rather than perform an extra conversion step, suggest that you use a better tool such as minicom, which has a built-in hex display mode. Addendum Switching to minicom fixed it! So apparently there's an issue when you perform the conversion "using vscode". This result is consistent with your other testing of "adding a buffer with a long string message and sending that over and over, and it is sent and received correctly." In hindsight, the next step in your testing could have been to perform the same conversion "using vscode" on this text data. Presumably you would not get the expected ASCII code values, and would then suspect that this conversion step was faulty. It's being sent from the USB-A port on the Nucleo, so maybe that's why it's ttyACM0? Yes. That is a USB-to-USB connection using CDC ACM, a protocol that can be used for emulating serial ports over USB. The PC is the USB host (as always), and the Nucleo board is a USB gadget implementing a virtual COM port. There is no (actual) UART or USART involved with such a USB connection, so you are not "send[ing] this data over UART", nor is the USART2 Mode and Configuration relevant. When your Nucleo program uses the HAL to access the huart2 pseudo-device, apparently this third "UART" is the virtual COM port using the USB connection. Assuming that the huart2 pseudo-device refers to the third USART device, USART2, is incorrect.
Setting up ETH ethernet on a custom carrier with TQMa6UL2-AA
I'm setting up a custom carrier board made in my company with one TQMa6UL2-AA i.MX6UL based on evaluation board of TQ stka6ul. I already have a booteable image with u-boot and linux generated with Yocto-Project and TQ BSP. I'm traying to set-up the two ethernet interfaces, In u-boot I could see the interfaces: => mii info PHY 0x00: OUI = 0x01F0, Model = 0x0F, Rev = 0x01, 100baseT, FDX PHY 0x01: OUI = 0x01F0, Model = 0x0F, Rev = 0x01, 100baseT, FDX And, if I config the IP address, I could make a ping to one computer, so I think the hardware is working,however, in Linux I couldn't see nothing. I don't know how I could fix this problem, I suppose the Linux kernel can't recognize the PHY but I don't know why. Could anyone help with my problem? Regards,
PN532 can't read NFC card type B
I'm trying to use the PN532 by Elechouse V3 connected through i2c to the raspberry-pi to read debit and credit card and I manage to read the type-A card successfully. I can't read the type-b cards though. These are the step I'm following according to the manual https://www.nxp.com/docs/en/user-guide/141520.pdf: Setting SAM configuration to normal mode sending bytes [0xD4, 0x14, 0x01, 0x01, 0x00] (not sure this is required though) Sending InListPassiveTarget with bytes [0xD4, 0x4A, 0x01, 0x03, 0x01] I was expecting to be able to read the type-B cards at this point but nothing happens when I try to put a card close to the reader. I've also tried changing the RF configuration settings sending the bytes [0xD4, 0x32, 0x0C, 0xFF, 0x17, 0x85] before the InListPassiveTarget and also tried using the InAutoPoll method with all the possible values but still no luck. Any idea or suggestion would be really appreciated