I am reading from COM port (communicating with RS-232).
I noticed a strange behavior when Win32 was reading 0x00 characters. I confirmed it by sending all possible combinations (from 0x00 to 0xF):
0x00 is read as 0x20.
Since my code can read all other Hex data, it is not a code issue right?
ANSWER TO MY QUESTION:
I forgot I replaced the input 0 character with the space character:
else if(buf[i] == 0)
{
//usually this happens in the beggining of a line.
buf[i] = ' ';//null
}
because usually every line I was reading was starting with 0.
So I removed the above code in my main and it fixed
Related
I'm using a PIC18 to write to SD cards via SPI. For many cards, this is working file BUT for some cards I pass the init process but when trying to write to the card, CMD24 returns 0x05 (which I believe is a CRC error)
// send CMD24 - preparing for a 512 byte block
SD_command(CMD24, 0x0001, CMD24_CRC);
// read response
res1 = SD_readRes1(); //This returns 0x05 for some cards!
I have used CMD59 - CRC_ON_OFF with parameter 0x00 to turn of CRC, and the command seems to complete. Is there something I am missing?
I read a comment of someone on a forum, who spent one week looking for an error in this code. In his case, he found that with some sd cards, he has to put a valid crc in the sd command, whatever the state of crc check option (cmd59).
Maybe it is simpler to put a valid crc in all cases.
I want to read around 336 bytes of data from NVRAM using Read Memory By Address UDS service. The command I am giving is "23 22 1C 22 01 50", where
0x23 - UDS command for Read Memory By Address
0x22 - Address and Length Format Identifier (Memory
address parameter - 2 and Memory size parameter 2)
0x1C 0x22 - Memory Address in 2 bytes
0x01 0x50 - Data length to read in 2 bytes (length is 336 bytes)
When I submit the command, I am getting "0x13 Incorrect Message Length or Invalid Format Error".
Can someone help me fixing this problem.
Thanks in advance.
Reference: https://piembsystech.com/uds-protocol/
What NRC 0x13 means
According to ISO 14229-1:2020:
This means:
SID 0x23 is supported by the server otherwise you would receive NRC 0x11 serviceNotSupported
Your request has inproper format (it is either too long or too short), in other cases you would receive other NRC (e.g. 0x31 requestOutOfRange). I suspect that address value is not 2 bytes long. It might be 4 bytes long (it depends on the memory type and size), but it is just a guess.
How to send the request properly
Well we do not know what is the exact format that the server accepts (it depends on memory of the server), but the ISO 14229-1:2020 define SID 0x23 request format as below:
I would try following request:
0x22 0x44 0x00 0x00 0x1C 0x22 0x00 0x00 0x01 0x50
where:
0x00 0x00 0x1C 0x22 - 4-byte memoryAddress
0x00 0x00 0x01 0x50 - memorySize (it is also 4 byte to make sure that addressAndLengthFormatIdentifier is properly interpreted by the server)
Other options
Server might have defect(s) (especially if you succesfully read memory using 2-byte-long address) and incorrectly display NRC 0x13 or have only support for certain value of addressAndLenghtFormatIdentifier. It is hard to judge with 100% certainty though. You would have provide at least one request with positive response.
Please do so in the comment and I am going to guide you through the problem.
I am having trouble reading and writing to different NFC tags with OMNIKEY 5426G2.
I can read and write the first 16 pages (4 bytes each) but the moment I send a command to read the 17th page - I get an error 0x6A 0x82 which means that address does not exist.
For example sending 0xFF 0xB0 0x00 0x06 0x04 gets me the 4 bytes on the 6th page
But when I do 0xFF 0xB0 0x00 0x10 0x04 - I get 0x6A 0x82 in return saying that this address does not exist.
All the tags that I use have this problem - different NTAG's, Mifare Ultralight C tags but ICODE SLIX tags are fine.
P.S. The same PC/SC commands work perfectly fine with ACR1252 reader so this is something related to OMNIKEY reader. Maybe some extra commands are missing.
P.P.S. Strange thing is that I can read/write all the bytes and pages by using a demo version of this library https://smartcard-api.com/buy-smart-card-api-library-license/
And since they are also using PC/SC commands - it clearly says that I am missing something.
Please help me understand what is going on. Thanks!
I'm trying to switch a Mifare Plus card into SL1 mode using an Omnikey 5421, however using the "Generic card command" interface as instructed by the documentation does not seem to work (card does not return any kind of output except 0x9000 which seems to be only an ACK that the command was sent succesfully - there should be additionaly bytes in the response before 0x90 0x00 which come from the chip itself).
The sequence is sent using SCardTransmit:
0xFF 0xA0 0x00 0x07 0x03 0x01 0x00 0x01 - enter generic session - returns 0x9000
... additional commands using documentation:
0xFF 0xA0 0x00 0x05 6+n 01 00 F3 00 00 64 + Mifare+ command 00 - returns 0x9000 whatever the command, even if invalid Mifare+ commands
0xFF 0xA0 0x00 0x07 0x03 0x01 0x00 0x02 - exit generic session - returns 0x9000 still
The only commands that seem to work are enter and exit, any other command that I send in between does not seem to have any effect, including RATS, Writeperso or Commitperso. When I add the 00 Le byte at the end the return code is 0x6400 instead of 0x9000, even though the docs say that Le byte should be appended when issuing Mifare+ commands.
All other operations work ok once the cards is personalized in SL1 mode (read, write, authenticate). I can already switch the card to SL1 mode using android NFC, so it does not seem to be a problem with the algorithm or the card.
I've tried to use command from the PC/SC part 3 documentation, but the return code is "not supported", so it seems that only this mechanism of transparent channel is available to issue 14443A commands.
In SL0 and SL3, You may directly call the Plus command via Generic Card Command.
"generic session" should be for SL1 to accept Plus command(as by default it goes to mifare classic mode)
"Hey bro, what's up ?"
I'm in trouble with NDEF message formatting.
I went through the NFC forum to know how to build a NDEF message with a single NDEF record (text RTD) with a payload, so I can program my tag (M24LR16E) through I2c.
In addition to this, I programmed my tag with an external writer to have an example of a well formatted record.
Then I programmed my tag through I2C with the exact same value, and everything worked well. Changing the payload characters gave me the proof of my success =)
"But you didn't come here to show us that anything worked well, no?"
You're right, know I'm trying to change the payload length and I get troubles. As soon as I change the PAYLOAD_LENGTH of the NDEF record it is no more recognized anymore as one. I changed the PAYLOAD_LENGTH from 10 down to 5, so it's not a problem of overflowing the config field.
"Great story, show me some code/config"
Here is my record configuration :
"Header" (MB ME CF SR IL TNF) : 0xD1
PAYLOAD_LENGTH : 0x0A
TYPE LENGTH : 0x01
TYPE : 0x54
PAYLOAD :
0x02 ; UTF-8, 2 byte language code
0x65 ; e
0x6E ; n
7 Other boring bytes
Also, I noticed that if I override the 6 bytes before my NDEF message, the NDEF message isn't recognized anymore. I have no idea on what could be this data as the NFC specification doesn't talk about this, neither the tag datasheet.
"You're supposed to ask a question..."
Uh, well...
Is there anything else than the PAYLOAD_LENGTH field of the NDEF record that I should change?
What are those essential data before my NDEF message?
My reader: Nexus 4 with NXP's "TagInfo" app
Unfortunately, you won't find much information on how to use that tag to store NDEF messages on the NFC Forum website. The reason for this is that there is currently no Tag Type specifiction for ISO 15693 tags (though standardization is ongoing).
I assume the memory contents of the tag looks like this (including the bytes you did not understand):
E1 4x yy 00
03 0E <YOUR NDEF MESSAGE> FE
If that's the case, the first 4 bytes are the capability container (indicated by the magic byte 0xE1 and the version nibble 0x4). x shoud be 0x0 indicating (application level!) read & write access. yy should be the overall size of your available data memory (excluding capability container) divided by 8. So far you should be able to keep those values...
But then there is the NDEF message TLV structure which embeds your NDEF message: 0x03 is the tag indicating an NDEF message. 0x0E is the length field. So that's what you need to change in addition to the payload length of your record. Android is quite picky when it comes to that length field. If this does not match the exact length of your NDEF message, most Android versions will ignore the message. The last byte, 0xFE is the (optional) terminator TLV. This should immediately follow the last data byte on your tag to tell the NDEF tag parser to stop parsing.