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.
Related
I'm using an NTAG I2C plus 2k memory tag and am able to successfully perform a FAST_READ for a particular page address range, but just beyond the range I'm getting an error.
iOS
Start address 0x04 and end address 0x46 reads successfully
await cmd([0x3a, 0x04, 0x46]);
while, start address 0x04 and end address 0x47 fails with
await cmd([0x3a, 0x04, 0x47]);
Error
input bytes: 3A0C0C
input bytes: 3A0447
[CoreNFC] 00000002 816c6760 -[NFCTagReaderSession transceive:tagUpdate:error:]:771 Error Domain=NFCError Code=100 "Tag connection lost" UserInfo={NSLocalizedDescription=Tag connection lost}
Android
Start address 0x04 and end address 0x49 reads successfully
await cmd([0x3a, 0x04, 0x49]);
while, start address 0x04 and end address 0x4b fails with
await cmd([0x3a, 0x04, 0x4b]);
Error
D/NfcService: Transceive start
D/NfcService: Transceive End, Result: 0 mTransceiveSuccess: 1 mTransceiveFail: 0
D/NfcService: Transceive start
D/NfcService: Transceive End, Result: 2 mTransceiveSuccess: 1 mTransceiveFail: 1
D/ReactNativeNfcManager: transceive fail: android.nfc.TagLostException: Tag was lost.
I/ReactNativeJS: Error: transceive fail
Thanks in advance.
From the Tag's datasheet
Remark: The FAST_READ command is able to read out the entire memory of one sector with one command. Nevertheless, the receive buffer of the NFC device must be able to handle the requested amount of data as no chaining is possible
When I do a FAST_READ on a similar Tag type on Android in native code I do a getMaxTransceiveLength to find out how big the buffer is and divide that by 4 and round down to find the max number of pages a FAST_READ can do at once and break up in to multiple FAST_READ's if necessary.
Generally the max Transceive length is 253 bytes on Android or 63 pages.
The react-native-nfc-manager API for Android also has getMaxTransceiveLength in it's API so you can do the same calculation of the maximum pages a FAST_READ can do on your hardware.
I've not done FAST_READ's on iOS but expect there is a similar limit (it does have an error code for transceive packet too large but I've not seen a way to ask it the max transceive length before you send a command)
While probably getMaxTransceiveLength is meant for size of sending command this amount of bytes should be able to be returned before the transceive timeout is hit, as the send and receive data rate is identical.
The transceive timeout can set but not got using react-native-nfc-manager API
Again no options on changing any timeout values in iOS but there is an error to indicate that the communication to the Tag has timed out.
So you could try increasing the timeout value on Android instead of breaking up in to a number of FAST_READ's but working out how long the timeout should be could be difficult and might have a negative impact if you set it too big.
For Android it's probably easier to assume the max send size is safe to receive as well. For iOS assume a max receive size from your experiments or handle the error and re-read with a back off algorithm.
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 trying to read a DTC from a CAPL script. I am using "(0x19) ReadDtcInformation - Report DTC snapshot record by DTC number" protocol service. My DTC number is 0x062003. I am able to set DTC number correctly. But, I am not able to set DTC status bits.
1. diagRequest FR_Diagnostic.FaultMemory_ReadEnvironmentData PWM_Status; // 0x19 0x94
2. diagSetParameter(PWM_Status,"DTC",0x062003); // 0x06 0x20 0x03
3. diagSetParameter(PWM_Status,"DtcSnapshotRecordNumber",0xFF);
4. DiagSendRequest(PWM_Status);
Line #3 is not quite setting DtcSnapshotRecordNumber to 0xFF. I see this field as 0x00 in trace.
Question:
1. Am I using correct API in line #3? How do I set DtcSnapshotRecordNumber to read for all the status bits? (there are 8 status bits to monitor, thus it should be set to 0xFF).
Normaly you call service 0x19 (Diagnostic) then call Subfunction and then you provide a bitmask which contains information for what you are searching.
So everything you need is defined in ISO 14229 Road vehicles.
Most services regarding DTCs and OBD stuff are the same across all OEMs. Each OEM normaly has a Diagnostic Specification Supplement which describes OEM specific Diagnostic services and so on.
In CAPL there is normaly an easy way to read out DTCs. You don´t need to do it manually as it is provided by the CDD-File. You can see it in the Object Browser of CAPL Brower on the right side.
So for your case for egg. retrieve number of DTCs which match your Mask:
Subfunction Report DTCByStatusMask 0x02
0x1902
The mask which is your search filter will be build like this:
bit # hex state description
0 0x01 testFailed DTC failed at the time of the request
1 0x02 testFailedThisOperationCycle DTC failed on the current operation cycle
2 0x04 pendingDTC DTC failed on the current or previous operation cycle
3 0x08 confirmedDTC DTC is confirmed at the time of the request
4 0x10 testNotCompletedSinceLastClear DTC test not completed since the
last code clear
5 0x20 testFailedSinceLastClear DTC test failed at least once since last code clear
6 0x40 testNotCompletedThisOperationCycle DTC test not completed this operation cycle
7 0x80 warningIndicatorRequested Server is requesting warningIndicator to be active
So if you just want to read out DTC which are confirmed (stored) than you send:
0x190208
If you get a positive response than the DTCs will be retrieved in Hex Format. You´ll need a HEX->SAE converter which will convert retrieved DTCs to regular know format. Anyway you can Test it through Diagnostic Console.
Answering myself:
Yes, I was using the correct API.
It wasn't getting set properly because the datatype used in the database (.cdd) files was wrong.
I could have converted .cdd file to template and edit the template and work with updated .cdd file, but I chose to work it out using a fresh template copy.
i am looking for APDU to find UID of contact less ISO 14443 smart card and how to use it to print in Linux terminal. Problem is that i found many people talking about it, but there is no solution. Can anyone help is this regard???
Thanks
"Get Data Command" is defined in PCSC 3 v2. If your driver is PCSC v2 compliant, you can get UID using it:
Class = 0xFF
INS = 0xCA
P1 = 0x00
P2 = 0x00
Le = 0x00 (return full length: ISO14443A single 4 bytes, double 7 bytes, triple 10 bytes, for ISO14443B 4 bytes PUPI, for 15693 8 bytes UID)
Returned value is:
Data+SW1SW2
See the other answer, it is likely that most readers do support the pass through to the card reader by now.
Nobody can help as the UID is specified in the ISO 14443 T=CL transport protocol while APDU's are specified in the ISO 7816 application layer protocol.
So you need access to a lower level API for your contactless reader. PCSC will not suffice (unless there has been a pass through implemented for the specific reader that returns the UID).
I'm developing a software utility to transfer some data to a pci-e board. To avoid the data transfer fault, I've add a CRC field in every packet, so that the pci-e board can verify the received data with the CRC value.
Then we found out that the CRC value failed to pass the verification.
I'm using the boost::crc_32_type to generate the CRC value while the hardware guy told me that the CRC implementation in the board is from http://www.easics.com/webtools/crctool and they're using the 64 data bus width version of CRC32 - ETHERNET / AAL5.
So, is it possible to use boost::crc_32_type to work with the one they're using?
Any suggestions will be greatly appreciated!
[edit 2013.02.20]
the working crc template shall have the following definition:
boost::crc_optimal<32, 0x04C11DB7, 0xFFFFFFFF, 0x0, false, false>
the order of every 8 bytes shall be reversed before being processed
std::for_each is used instead of process_bytes to get the result, I still don't quite understand the difference between them though.
You can use crc_32_type - first you have to make sure your bytes are going in the same order as the bytes the hardware guys are. The convention used by the EASICS code is that the first byte in the stream goes into Data[63:56].