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.
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 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'm writing firmware for a USB 2.0 full speed device that communicates with a WinUSB host, with one Bulk Pipe in each direction. When should the device send a zero-length packet (ZLP) to terminate an IN transfer, and how does it know that it should?
Section 5.8.3 of the USB 2.0 spec says:
A bulk transfer is complete when the endpoint does one of the following:
Has transferred exactly the amount of data expected
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet [ZLP]
I interpret this to mean that a ZLP should be sent when the transfer size is an integer multiple of the max packet size, and the "expected" size of the transfer is greater than the actual size (i.e. what is available to be sent). But how does the recipient know what's expected?
For instance, I'm using the WinUSBNet wrapper in C#. When I read from the pipe like this
int bytesRead;
buffer = new byte[128];
try
{
bytesRead = m_PipeIN.Read(buffer);
buffer = buffer.Take(bytesRead).ToArray();
}
the library calls WinUsb_ReadPipe() like this:
WinUsb_ReadPipe(InterfaceHandle(ifaceIndex),
pipeID,
pBuffer + offset,
(uint)bytesToRead,
out bytesRead,
IntPtr.Zero);
Suppose the device has exactly 128 bytes to send, and max packet size is 64 bytes. How does the device determine what the host is "expecting", thus whether it should send a ZLP to terminate the transfer?
(Similar to this question, but that one is about control pipes. I'm asking about bulk pipes.)
Explanation of the spec:
Case 1
Has transferred exactly the amount of data expected
This means that if the host is expecting X amount of bytes, and you send exactly X amount of bytes, the transfer stops right there. MPS and ZLP don't play into it.
Case 2
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet [ZLP]
This means that if the host is expecting X bytes but you want to send only Y bytes, where Y < X, the transfer is complete as soon as you do a "short" packet, a packet less the MPS. If Y bytes is a multiple of MPS, then you would have to do a ZLP.
Example 1 (no ZLP)
MPS = 512, the host expects 8192 bytes.
You want to send only 1500 bytes. The payload would go over in 3 packets like this:
Packet 0: [512 bytes] MPS
Packet 1: [512 bytes] MPS
Packet 2: [476 bytes] short packet
When the host gets the short packet, it knows the transfer is complete, and won't continue asking for more packets for the transfer.
Example 2 (with ZLP)
MPS = 512, the host expects 8192 bytes.
You want to send only 2048 bytes. The payload would go over in 4 packets like this:
Packet 0: [512 bytes] MPS
Packet 1: [512 bytes] MPS
Packet 2: [512 bytes] MPS
Packet 3: [512 bytes] MPS
At this point, the host has received 4 MPS-sized packets so it doesn't know the transfer is complete. So it will continue to request packets from the device.
Packet 4: [0 bytes] short packet (ZLP)
When the host gets the short packet, it knows the transfer is complete, and won't continue asking for more packets for the transfer.
Determining Transfer Size
You may be wondering how to determine the "expected" amount of bytes since BULK transfers do not have a length like CTRL transfers do. This is determined entirely by the higher-level protocol that specifies how to do transfers on the BULK pipes. The host and device both follow this protocol and thus they are in sync about how much data to transfer at any given time.
This protocol is typically specified by a class specification, like the mass-storage class protocol, or it could be some very simple protocol of your own design.
Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet [ZLP]
a ZLP has to be send when the length of payload data is exactly an integer multiple of wMaxPacketSize
The USB spec defines that if the last packet of a bulk transfer has
the exact size of the endpoint max packet size, the whole transfer
must be terminated by a zero length urb.
If apps don't sent this in such a situation libusb times out and the
initial urb is never sent resulting in a broken application.
All Kernel drivers use the URB_ZERO_PACKET to comply to the spec
correctly.
source: http://libusb.org/ticket/6
in case that data length is exactly an integer multiple of wMaxPacketSize
the first ending condition packetSize < wMaxPacketSize does not apply because in this case packetSize = wMaxPacketSize.
so to indicate the information that the last packet has been send you need a ZLP, else the other side would expect more data
there are several other situations when ZLPs are sent see i.e. USB in a nutshell website
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].
I'm processing Midi on the iPad and everything is working fine and I can log everything that comes in and all works as expected. However, in trying to recieve long messages (ie Sysex), I can only get one packet with a maximum of 256 bytes and nothing afterwards.
Using the code provided by Apple:
MIDIPacket *packet = &packetList->packet[0];
for (int i = 0; i > packetList->numPackets; ++i) {
// ...
packet = MIDIPacketNext (packet);
}
packetList->numPackets is always 1. After I get that first message, no other callback methods are called until a 'new' sysex message is sent. I don't think that my MIDI processing method would be called with the full packetList (which could potentially be any size). I would have thought I would recieve the data as a stream. Is this correct?
After digging around the only thing I could find was this: http://lists.apple.com/archives/coreaudio-api/2010/May/msg00189.html, which mentions the exact same thing but was not much help. I understand I probably need to implement buffering, but I can't even see anything past the first 256 bytes so I'm not sure where to even start with it.
My gut feeling here is that the system is either cramming the entire sysex message into one packet, or breaking it up into multiple packets. According to the CoreMidi documentation, the data field of the MIDIPacket structure has some interesting properties:
A variable-length stream of MIDI messages. Running status is not allowed. In the case of system-exclusive messages, a packet may only contain a single message, or portion of one, with no other MIDI events.
The MIDI messages in the packet must always be complete, except for system-exclusive.
(This is declared to be 256 bytes in length so clients don't have to create custom data structures in simple situations.)
So basically, you should look at the declared length field of the MIDIPacket and see if it is larger than 256. According to the spec, 256 bytes is just the standard allocation, but that array can hold more if necessary. You might find that the entire message has been crammed into that array.
Otherwise, it seems that the system is breaking the sysex messages up into multiple packets. Since the spec says that running status is not allowed, then it would have to send multiple packets, each with a leading 0xF0 byte. You would then need to create your own internal buffer to store the contents of these messages, stripping away the status bytes or header as necessary, and appending the data to your buffer until you read a 0xF7 byte which denotes the end of the sequence.
I had a similar issue on iOS. You are right MIDI packets number is always 1.
In my case, when receiving multiple MIDI events with the same timestamp (MIDI events received at the same time), iOS does not split those multiple MIDI events in multiple packets, as expected.
But, fortunately nothing is lost ! Indeed instead of receiving multiple packets with their correct number of bytes, you will receive a single packet with multiple events in it and the number of bytes will be increased accordingly.
So here what you have to do is:
In your MIDI IN callback, parse all packets received (always 1 for iOS), then for each packet received you must check the length of the packet as well as the MIDI status, then loop into that packet to retrieve all MIDI events in the current packet.
For instance, if the packet contains 9 bytes, and the MIDI status is a note ON (3 bytes message), that means your current packet contains more than a single note ON, you must then parse the first Note ON (bytes 0 to 2) then check the following MIDI status from byte 3 and so on ..
Hope this helps ...
Jerome
There is a good reference of how to walk through a MIDI packet in this file of a GitHub project : https://github.com/krevis/MIDIApps/blob/master/Frameworks/SnoizeMIDI/SMMessageParser.m
(Not mine, but it helped me solve the problems that got me to this thread)