PN532 can't read NFC card type B - raspberry-pi
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
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.
How to debug selectapdu from android nfc emulator to arduino with pn532?
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
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.
Cannot init NRF24L01+ registers using SPI and STM32F303
Am trying to initialize the NRF24L01+ registers using SPI but they always return 0x00. According to the datasheet, Table 20 on page 51, all write commands will have a pattern of b001x xxxx, which i understood as having a 0x2x pattern. In my snapshot below, i send the register value, for example register 0x00 will be sent as 0x20 indicating a write command to that register and then i send the value to be written on that register. As you see on the MISO line, the value is 0x00 even when am trying to write a 0x08 which should be the default value according to page 57 of the datasheet. I still dont know why its returning 0x00 even when i independently try to read the contents of that register later on without writing to it. I still get 0x00. The same applies to all other registers that am trying to re-init. Anyone who has experienced this behaviour elsewhere or is it me that is having something wrong? The NRF24 am trying to program here is this type from sparkfun
You are close. The datasheet shows write register as 001A AAAA and read as 000A AAAA, where the 5 A's represent the register you want to write to. The spec states that while the command is being sent (read, write, read payload, write payload, flush, activate, and so on), the device will return the status register. In your data, the device is responding with 0x0E, which is correct; decoded is is saying no errors and no data received or pending to transmit. If you want to see if the command you send was accepted, you need to first write the data and then read the data. For example, let's say we want to write the config register to enable the device as a receiver, 2 byte CRC with Rx interrupts enabled. First, you would send 0b00100000 (0x20), 0b00111111 (0x3F). The device will respond with 0b00001110 (0x0e), 0b00000000 (0x00). This is what you are seeing. If you want to verify the configuration register, you need to then send 0b00000000 (0x00),which is the command to read the config register, then 0b00000000 (0x00), which is a dummy byte to clock out the data. The device will respond with 0x0e, which is the status, and then 0x3F assuming you configured as I did above. Note that there are more commands than just reading and writing the registers, there are specific commands to fill and read the pipeline data. Hope this helps.
Printing Receipt on Star Micronics TSP 650 Printer through iPad
I am using Star iOS SDK to print receipts (like a restaurant bill) but am facing problems implementing column settings and cell spacing for proper alignment. I have checked out the documentation but have not found something useful. The line code manual has some signals/commands which I am unable to understand. Can anyone help me out with that?
The commands referenced in the Line Mode manual need to be converted into bytes and then sent to the printer. The StarIO iOS SDK package you downloaded has a manual called "README_StarIO_POSPrinter_iOS_SDK.pdf". (http://www.starmicronics.com/absolutefm/absolutefm/afmviewfaq.aspx?faqid=175) Did you check out pages 9-15? The StarIO framework is explained here.
Specific to your question about sending commands, page 13 shows you how to write to the port using a byte array, but make sure you add StarIO.framework and open the communication port first.
From the manual:
//Set a byte array to send to the printer
//command = { A, B, C, D, Feed 3mm, Full Cut}
unsigned char command = {0x41, 0x42, 0x43, 0x44, 0x1B, 0x7A, 0x00, 0x1B, 0x64, 0x02};
Uint bytesWritten = 0;
#Try
{
While(bytesWritten < (sizeof command))
{
bytesWritten += [port writePort: command : bytesWritten : sizeof command - bytesWritten];
}
}
#Catch(PortException)
{
//There was an error writing to the port
}
Also described is how to close ports (make sure you close every opened port) and getting printer status.
Let me know if this helps.
I talked to SDK developers of start micronics, as I was facing the same problem using TSP100 model. Here is the reply from one of their tech guy. "Unlike most of our other models the TSP100 series is a bit unique in that it is raster only meaning that it does not have the text formatting commands that our other printers do (ie, the printer just prints whatever receipt image you send it). Any formatting would be done in your application however you would like to do it before creating the image to send to the printer" So this is clear that you have to maintain the column width, formatting, alignment etc everything by yourself.