Hi
It seems to me that simtrace looses a byte between 2 URB transfers from the device. To trace the problem down, I wrote a little test-program, running the same APDU against the smart card. I’m using simtrace to trace the card on the HW level and at the very same time I trace on the PCSC layer of the OS. Of cause the 2 APDU traces should give exactly the same results. Surprisimgly I found that the simtrace is swallowing one byte between two URB chunks transferred.
Please find below the 2 logs A.) PCSC trace, B.) simtrace output. In this example simtrace is missing 1 byte (“7F”) between the two URB chunks a.) and b.). This missing byte causes to scrow up the analyser (APDU number 5). The same problem occurs also between the next two URB chunks b.) and c.): This time a “00” gets lost ... etc etc.
A.) The PCSC traces as reference: ======================================= 1.) transmitted: 80 C2 00 00 28 D8 00 01 6F 00 F5 EF BF B1 8C 76 16 00 0E 43 6F 6E 74 65 6E 74 4D 61 6E 61 67 65 72 00 C0 4B 4E 7F BD 00 04 4D 53 43 4D received: 61 05 2.) transmitted: 00 C0 00 00 05 received: 01 00 00 00 05 90 00 3.) transmitted: 80 C2 00 00 12 D8 00 05 6F 00 C0 4B 4E 7F BD DE EC 00 04 4D 53 43 4D received: 61 0F 4.) transmitted: 00 C0 00 00 0F received: 00 D2 5D 1C 11 27 00 07 37 2E 31 2E 30 2E 30 90 00 5.) transmitted: 80 C2 00 00 14 D8 00 05 6F 00 C0 4B 4E 7F BD 81 87 00 04 4D 53 43 4D 05 00 received: 61 1A 6.) transmitted: 00 C0 00 00 1A received: 00 D2 5D 1C 45 A3 00 00 00 10 2E 4E 45 54 57 01 13 51 21 9C 77 14 27 14 FF FF 90 00 7.) transmitted: 80 C2 00 00 12 D8 00 05 6F 00 C0 4B 4E 7F BD FA 3B 00 04 4D 53 43 4D received: 61 12 8.) transmitted: 00 C0 00 00 12 received: 00 D2 5D 1C 45 A3 00 00 00 08 83 17 65 55 19 7E A5 EB 90 00 9.) transmitted: 80 C2 00 00 1E D8 00 05 6F 00 C0 4B 4E 7F BD 24 FE 00 04 4D 53 43 4D 00 00 00 08 FC 66 34 93 BD 58 68 54 received: 90 00 10.) transmitted: 80 C2 00 00 13 D8 00 05 6F 00 C0 4B 4E 7F BD 6D 08 00 04 4D 53 43 4D 02 received: 61 0A 11.) transmitted: 00 C0 00 00 0A received: 00 D2 5D 1C 61 C0 00 00 00 05 90 00
B.) The simtrace output: ================================================ simtrace - GSM SIM and smartcard tracing (C) 2010 by Harald Welte laforge@gnumonks.org
Entering main loop URB: 01 01 00 00 3b 16 96 41 73 74 72 69 64 ATR APDU: 3b 16 96 41 73 74 72 69 64 a.) URB: 01 00 00 00 80 c2 00 00 28 c2 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 00 c0 00 00 05 c0 01 00 00 00 05 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f 00 c0 00 00 0f c0 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 80 c2 00 00 14 c2 d8 00 05 6f 00 c0 4b 4e 1.) APDU: 80 c2 00 00 28 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 2.) APDU: 00 c0 00 00 05 01 00 00 00 05 90 00 3.) APDU: 80 c2 00 00 12 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f 4.) APDU: 00 c0 00 00 0f 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 b.) URB: 01 00 00 00 bd 81 00 04 4d 53 43 4d 05 00 61 1a 00 c0 00 00 1a c0 00 d2 5d 1c 45 a3 00 00 00 10 2e 4e 45 54 57 01 13 51 21 9c 77 14 27 14 ff ff 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd fa 3b 00 04 4d 53 43 4d 61 12 00 c0 00 00 12 c0 00 d2 5d 1c 45 a3 00 00 00 08 83 17 65 55 19 7e a5 eb 90 00 80 c2 00 00 1e c2 d8 00 05 6f 00 c0 4b 4e 7f bd 24 fe 00 04 4d 53 43 4d 00 00 5.) APDU: 80 c2 00 00 14 d8 00 05 6f 00 c0 4b 4e bd 81 00 04 4d 53 43 4d 05 00 61 1a 00 c0 APDU: 00 00 1a c0 00 d2 5d APDU: 1c 45 a3 00 00 00 10 APDU: 2e 4e 45 54 57 01 13 APDU: 51 21 9c 77 14 27 14 APDU: ff ff 90 00 80 c2 00 APDU: 00 12 c2 d8 00 05 6f APDU: 00 c0 4b 4e 7f bd fa APDU: 3b 00 04 4d 53 43 4d APDU: 61 12 00 c0 00 00 12 APDU: c0 00 d2 5d 1c 45 a3 APDU: 00 00 00 08 83 17 65 APDU: 55 19 7e a5 eb 90 00 c.)URB: 01 04 00 00 08 fc 66 34 93 bd 58 68 54 d.)URB: 01 04 00 00 90 00 80 c2 00 00 13 c2 d8 00 05 6f 00 c0 4b 4e 7f bd 6d 08 00 04 4d 53 43 4d 02 61 0a 00 c0 00 00 0a c0 00 d2 5d 1c 61 c0 00 00 00 05 90 00 APDU: 80 c2 00 00 1e d8 00 05 6f 00 c0 4b 4e 7f bd 24 fe 00 04 4d 53 43 4d 00 00 08 fc 66 34 93 bd 58 68 54 90 00 80 APDU: c2 00 00 13 c2 d8 00 APDU: 05 6f 00 c0 4b 4e 7f APDU: bd 6d 08 00 04 4d 53 APDU: 43 4d 02 61 0a 00 c0 APDU: 00 00 0a c0 00 d2 5d APDU: 1c 61 c0 00 00 00 05 URB: 01 01 00 00 3b 16 96 41 73 74 72 69 64 ATR APDU: 3b 16 96 41 73 74 72 69 64
==========================================================
Is this a problem of simtrace or the firmware? Am I using a wrong firmware?
Thanks, Ben
Hi Ben, On Sat, Feb 11, 2012 at 10:42:32PM +0100, Myonium wrote:
It seems to me that simtrace looses a byte between 2 URB transfers from the device. To trace the problem down, I wrote a little test-program, running the same APDU against the smart card.
Interesting. This hasn't been seen so far. Can you please let us know more about your setup, particularly the baud rate you're running at? My immediate assumption would be that the PPS is selecting a high-speed rate and we run into an overflow somewhere, possibly in reading the UART FIFO.
If you can force your reader to use a lower rate (e.g. by using a very old card, or explicit commands on the host/reader side) it would be worth trying it at different speeds and checking if there is any change in behavior.
Regards, Harald
It seems to me that simtrace looses a byte between 2 URB transfers from the device. To trace the problem down, I wrote a little test-program, running the same APDU against the smart card.
Interesting. This hasn't been seen so far.
Actually I think that's what I've noticed when I try listening to the communication between a LTE mifi and the SIM, except I was loosing two chars from time to time.
I never got to the bottom of the issue tough, but at least I can reproduce it locally and have a deeper look.
Cheers,
Sylvain
On Feb 12, 2012, at 11:04 AM, Harald Welte wrote:
It seems to me that simtrace looses a byte between 2 URB transfers from the device. To trace the problem down, I wrote a little test-program, running the same APDU against the smart card.
Interesting. This hasn't been seen so far. Can you please let us know more about your setup, particularly the baud rate you're running at? My immediate assumption would be that the PPS is selecting a high-speed rate and we run into an overflow somewhere, possibly in reading the UART FIFO.
If you can force your reader to use a lower rate (e.g. by using a very old card, or explicit commands on the host/reader side) it would be worth trying it at different speeds and checking if there is any change in behavior.
Thank you for the fast reply. Your assumption (speed issue) most probably right. It happened to me with a new “Gemalto .NET v2.0” card which has baud rates up to 223kbps. Would the simtrace device give me the transfer rate? How would you suggest to measure it?
To contrast it, I run the same setup (different APDUs) with a "old" Cyberflex 32k card. => I got a 100% match. No bytes lost. It's not a general issue.
Btw. a neat idea to run the card with a different speed when tracing ....
Interesting to see from the traces (new Gemalto .NET v2.0 card), that there is not PPS negotiation. I would probably have to make a warm reset to trigger that. Indeed that would be a nice experiment also I currently have no clue how to do it ... in theory that would be something, which could be included into the firmware ... what do you think? (The simtrace firmware would always negotiate a speed it could handle ....)
Regards, Ben
Hi again,
On Sun, Feb 12, 2012 at 02:46:37PM +0100, Myonium wrote:
Thank you for the fast reply. Your assumption (speed issue) most probably right. It happened to me with a new “Gemalto .NET v2.0” card which has baud rates up to 223kbps. Would the simtrace device give me the transfer rate? How would you suggest to measure it?
If you look at the serial console, it should even tell you the negotiated PPS settings. So far there is no code to export this via USB t othe host PC, as far as I remember. However, it would be simple to add it in case you don't happen to have a matching serial cable. Please let me know.
Btw. a neat idea to run the card with a different speed when tracing ....
Interesting to see from the traces (new Gemalto .NET v2.0 card), that there is not PPS negotiation. I would probably have to make a warm reset to trigger that. Indeed that would be a nice experiment also I currently have no clue how to do it ... in theory that would be something, which could be included into the firmware ... what do you think? (The simtrace firmware would always negotiate a speed it could handle ....)
Well, I think that the firmware can be fixed to handle all the speeds, and we should try that as a primary goal. But yes, twisting the ATR bytes in order to ensure the Fi/Di values cannot be selected above a certain speed might very well be a nice idea. It's more in the area of a man-in-the-middle than a purely passive trace, though.
On Sun, Feb 12, 2012 at 03:22:41PM +0100, Harald Welte wrote:
Hi again,
On Sun, Feb 12, 2012 at 02:46:37PM +0100, Myonium wrote:
Thank you for the fast reply. Your assumption (speed issue) most probably right. It happened to me with a new “Gemalto .NET v2.0” card which has baud rates up to 223kbps. Would the simtrace device give me the transfer rate? How would you suggest to measure it?
If you look at the serial console, it should even tell you the negotiated PPS settings. So far there is no code to export this via USB t othe host PC, as far as I remember. However, it would be simple to add it in case you don't happen to have a matching serial cable. Please let me know.
I've quickly implemented this, but don't have time to test it right now.
Please update your simtrace host utility to rev. b14d0ad2792d3f76ec21e141229840c736a2f23c or later, and use firmware 4f7ca20bf40b911c035264d86ef0359d20e7ac88 or later. I've attached a firmware image (for dfu-util flashing) for your reference.
The simtrace program on the host pc should print something like PPS(Fi=X/Di=Y) once a PPS happens, using the values that were obtained from the acual PPS sniffing.
Regards, Harald
Hi again,
On Sun, Feb 12, 2012 at 02:46:37PM +0100, Myonium wrote:
Thank you for the fast reply. Your assumption (speed issue) most probably right. It happened to me with a new “Gemalto .NET v2.0” card which has baud rates up to 223kbps. Would the simtrace device give me the transfer rate? How would you suggest to measure it?
If you look at the serial console, it should even tell you the negotiated PPS settings. So far there is no code to export this via USB t othe host PC, as far as I remember. However, it would be simple to add it in case you don't happen to have a matching serial cable. Please let me know.
I've quickly implemented this, but don't have time to test it right now.
Please update your simtrace host utility to rev. b14d0ad2792d3f76ec21e141229840c736a2f23c or later, and use firmware 4f7ca20bf40b911c035264d86ef0359d20e7ac88 or later. I've attached a firmware image (for dfu-util flashing) for your reference.
The simtrace program on the host pc should print something like PPS(Fi=X/Di=Y) once a PPS happens, using the values that were obtained from the acual PPS sniffing.
Unfortunately ,there seems to be a bug in firmware rev. 4f7ca20bf40b911c035264d86ef0359d20e7ac88. I tested on my device "v1.1p": ATR don’t get through anymore. Just a “b3” byte. The smart card isn’t responding to a reset ...
I had to go back to firmware “v0.4”. Than it is working again ... tried the process twice back and forth... will have a look at the code of the new revision next weekend.
In the meantime I found a serial cable: On the console I get the following output:
found Fi=9 Di=6 computed Fi(9) Di(6) ratio: 16 __pio_irq_demux(43): PIO_ISR_STATUS = 0x11e006d6 RST computed Fi(1) Di(1) ratio: 372 __pio_irq_demux(43): PIO_ISR_STATUS = 0x11800494 RST computed Fi(1) Di(1) ratio: 372
I compiled the firmware “v0.4” with DEBUG=0. About 1 of 5 runs, it works with no bytes lost. In the other 4 runs bytes are swallowed between URB chunks ...
What do you think would be the maximum speed the current HW (v1.1) could handle (if tuned a little bit ;-) ?
Thanks, Ben
On 02/14/2012 11:41 PM, Myonium wrote:
What do you think would be the maximum speed the current HW (v1.1) could handle (if tuned a little bit ;-) ?
Hi,
just from the expectation: The SAM7 should support all modes of ISO 7816-3 so I would expect that the SIMtrace works with all of them as well. My debug proposal would be:
Topic: Find out where the byte(s) is lost.
How: I am not sure if the debug uart code is IRQ driven and if it has a rather long queue.. but... I would start by dumping every received byte to the other UART and compare the results.
Reasoning: This should isolate the problem to be either on the USART (receiving data properly) or in our USB code.
Before one starts: Are you sure that the data is missing in the 'URB', in contrast to the host utility losing them when splitting APDUs?
On Feb 15, 2012, at 11:14 AM, Holger Hans Peter Freyther wrote:
Before one starts: Are you sure that the data is missing in the 'URB', in contrast to the host utility losing them when splitting APDUs?
Yes, I printed out the URB from simtrace. That was the way I discovered the missing bytes. Of cause the APDU analyzer screws up if a byte is missing.
Missing bytes were (in all cases I analyzed) always between URB chunks. Please find below 2 samples:
Sample A.) In this case between URB a.) and b.) the byte "7F" gets lost. The last APDU should be " 80 C2 00 00 14 D8 00 05 6F 00 C0 4B 4E 7F BD 81 87 00 04 4D 53 43 4D 05 00". ATR APDU: 3b 16 96 41 73 74 72 69 64 a.)URB: 01 00 00 00 80 c2 00 00 28 c2 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 00 c0 00 00 05 c0 01 00 00 00 05 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f 00 c0 00 00 0f c0 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 80 c2 00 00 14 c2 d8 00 05 6f 00 c0 4b 4e APDU: 80 c2 00 00 28 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 APDU: 00 c0 00 00 05 01 00 00 00 05 90 00 APDU: 80 c2 00 00 12 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f APDU: 00 c0 00 00 0f 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 b.)URB: 01 00 00 00 bd 81 87 00 04 4d 53 43 4d 05 00 61 1a 00 c0 00 00 1a c0 00 d2 5d 1c 45 a3 00 00 00 10 2e 4e 45 54 57 01 13 51 21 9c 77 14 27 14 ff ff 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd fa 3b 00 04 4d 53 43 4d 61 12 00 c0 00 00 12 c0 00 d2 5d 1c 45 a3 00 00 00 08 ef d2 66 21 9d 45 61 5c 90 00 80 c2 00 00 1e c2 d8 00 05 6f 00 c0 4b 4e 7f bd 24 fe 00 04 4d 53 43 4d 00 APDU: 80 c2 00 00 14 d8 00 05 6f 00 c0 4b 4e bd 81 87 00 04 4d 53 43 4d 05 00 61 1a 00
Sample B.) In this Sample the byte "BD" is lost. (Again the last APDU should be " 80 C2 00 00 14 D8 00 05 6F 00 C0 4B 4E 7F BD 81 87 00 04 4D 53 43 4D 05 00".) ATR APDU: 3b 16 96 41 73 74 72 69 64 URB: 01 00 00 00 80 c2 00 00 28 c2 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 00 c0 00 00 05 c0 01 00 00 00 05 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f 00 c0 00 00 0f c0 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 80 c2 00 00 14 c2 d8 00 05 6f 00 c0 4b 4e APDU: 80 c2 00 00 28 d8 00 01 6f 00 f5 ef bf b1 8c 76 16 00 0e 43 6f 6e 74 65 6e 74 4d 61 6e 61 67 65 72 00 c0 4b 4e 7f bd 00 04 4d 53 43 4d 61 05 APDU: 00 c0 00 00 05 01 00 00 00 05 90 00 APDU: 80 c2 00 00 12 d8 00 05 6f 00 c0 4b 4e 7f bd de ec 00 04 4d 53 43 4d 61 0f APDU: 00 c0 00 00 0f 00 d2 5d 1c 11 27 00 07 37 2e 31 2e 30 2e 30 90 00 URB: 01 00 00 00 7f 81 87 04 4d 53 43 4d 05 00 61 1a 00 c0 00 00 1a c0 00 d2 5d 1c 45 a3 00 00 00 10 2e 4e 45 54 57 01 13 51 21 9c 77 14 27 14 ff ff 90 00 80 c2 00 00 12 c2 d8 00 05 6f 00 c0 4b 4e 7f bd fa 3b 00 04 4d 53 43 4d 61 12 00 c0 00 00 12 c0 00 d2 5d 1c 45 a3 00 00 00 08 51 e6 e0 88 2a 26 cb 51 90 00 80 c2 00 00 1e c2 d8 00 05 6f 00 c0 4b 4e 7f bd 24 fe 00 04 4d 53 43 4d 00 00 APDU: 80 c2 00 00 14 d8 00 05 6f 00 c0 4b 4e 7f 81 87 04 4d 53 43 4d 05 00 61 1a 00 c0
I will try to analyse this ... as I can only spend time in the evenings for that, it will take me some time ...
Regards, Ben
Myonium wrote:
I printed out the URB from simtrace.
You could have a look using usbmon as well. mount debugfs, then build and run http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz on the bus.
//Peter
Thanks, Peter, please find below the first results from the “speed issue” analysis:
1.) I contrasted the URB chunks received in “simtrace host” with the usbmon output. => There is a 100% match. No data is lost in the “simtrace host program”. 2.) I increased and decreased the buffer size (rctx) of the firmware. => If there were bytes lost, than always between URB chunks. Decreasing the buffer size improved the situation a lot! Reducing the buffer size from 128B (default) to 32B almost eliminated the lost byte problem (1 of 5 failed). With a buffer size of 16B I never had a lost byte.
=> Conclusion: The send_rctx with a “large” buffer is so expensive, that we are loosing bytes while sending the chunk. It solved the problem for me, by setting the buffer to 16B. However any idea how we could lighten the send data process? Any other conclusions?
Regards, Ben
On Feb 17, 2012, at 12:11 AM, Peter Stuge wrote:
Myonium wrote:
I printed out the URB from simtrace.
You could have a look using usbmon as well. mount debugfs, then build and run http://people.redhat.com/zaitcev/linux/usbmon-6.tar.gz on the bus.
//Peter
Myonium wrote:
Thanks, Peter, please find below the first results from the “speed issue" analysis:
Good work.
1.) I contrasted the URB chunks received in “simtrace host” with the usbmon output. => There is a 100% match. No data is lost in the “simtrace host program”.
Ok.
2.) I increased and decreased the buffer size (rctx) of the firmware. => If there were bytes lost, than always between URB chunks. Decreasing the buffer size improved the situation a lot! Reducing the buffer size from 128B (default) to 32B almost eliminated the lost byte problem (1 of 5 failed). With a buffer size of 16B I never had a lost byte.
=> Conclusion: The send_rctx with a “large” buffer is so expensive, that we are loosing bytes while sending the chunk. It solved the problem for me, by setting the buffer to 16B. However any idea how we could lighten the send data process? Any other conclusions?
Your findings make sense.
I note that all data to be transmitted is copied byte for byte from the rctx data buffer into the USB peripheral memory. I had expected zero copy. During copying, interrupts are disabled.
Basically the USB "framework" would need to be rewritten specifically for zero copy operation, if the hardware actually allows that.
Meanwhile, going down to 16 or even 8 bytes per packet is fine IMO.
//Peter
Hi Peter and others,
On Sat, Feb 18, 2012 at 08:18:33PM +0100, Peter Stuge wrote:
I note that all data to be transmitted is copied byte for byte from the rctx data buffer into the USB peripheral memory. I had expected zero copy. During copying, interrupts are disabled.
Basically the USB "framework" would need to be rewritten specifically for zero copy operation, if the hardware actually allows that.
unfortunately the old USB peripheral in the sam7s does not have DMA, you have to use FIFO / MMIO to put the data onto USB. It's really sad, almost all other peripherals can do DMA, but not the USB device controller.
I'd love to investigate this further, but I don't have the time right now, sorry :/
Harald Welte wrote:
Basically the USB "framework" would need to be rewritten specifically for zero copy operation, if the hardware actually allows that.
unfortunately the old USB peripheral in the sam7s does not have DMA, you have to use FIFO / MMIO to put the data onto USB. It's really sad, almost all other peripherals can do DMA, but not the USB device controller.
I figured as much. Perhaps writing to the FIFO can happen already when initially receiving the data from the serial port, ie. without first storing to a buffer in RAM. But I think this will have some non-trivial consequences for the code.
//Peter
Peter Stuge wrote:
Perhaps writing to the FIFO can happen already when initially receiving the data from the serial port
Another approach is to do copying with interrupts enabled. It might then instead require a bit from the buffer management, to avoid the receive interrupt from stomping on unsent data.
//Peter
Hi
On Sun, Feb 19, 2012 at 1:02 AM, Peter Stuge peter@stuge.se wrote:
Peter Stuge wrote:
Perhaps writing to the FIFO can happen already when initially receiving the data from the serial port
Another approach is to do copying with interrupts enabled. It might then instead require a bit from the buffer management, to avoid the receive interrupt from stomping on unsent data.
Are FIQ disabled as well ? Or could we move uart RX to fiq ?
Cheers,
Sylvain
On Sun, Feb 19, 2012 at 10:03:30AM +0100, Sylvain Munaut wrote:
Hi
On Sun, Feb 19, 2012 at 1:02 AM, Peter Stuge peter@stuge.se wrote:
Peter Stuge wrote:
Perhaps writing to the FIFO can happen already when initially receiving the data from the serial port
Another approach is to do copying with interrupts enabled. It might then instead require a bit from the buffer management, to avoid the receive interrupt from stomping on unsent data.
Are FIQ disabled as well ? Or could we move uart RX to fiq ?
IIRC, the UART is even DMA capable (via the PDC), but the problem is that we have to act on each byte in realtime to watch for Fi/Di changes (PPS) which can occur basically at any time. So I think it will have to remain software manually pulling out each byte from the UART.
Hi Peter and others,
On Sat, Feb 18, 2012 at 08:18:33PM +0100, Peter Stuge wrote:
I note that all data to be transmitted is copied byte for byte from the rctx data buffer into the USB peripheral memory. I had expected zero copy. During copying, interrupts are disabled.
I'm actually not sure on the latter part:
* the hardware and IRQ handler code supports nested interrupts * the core IRQ handler assembly code re-enables interrupts immediately even before calling the USB driver * the endpoint re-fill code called from the irq handler __udp_refill_ep() doesn't contain any explicit local_irq_disable() * the USART interrupt priority (4) is higher than the USB prio (2)
So based on all this, the USART interrupt should happily be served as a nested IRQ even while the USB driver is re-filling the end-point FIFO.
Regards, Harald
On Feb 15, 2012, at 11:14 AM, Holger Hans Peter Freyther wrote:
How: I am not sure if the debug uart code is IRQ driven and if it has a rather long queue.. but... I would start by dumping every received byte to the other UART and compare the results.
Not sure if I got you right ... what I tried was the following ...
In “simtrace/iso7816_uart.c” I added to the function “process_byte” a line to dump all bytes “DEBUGPCR("IN=0x%08x", byte);”
First the reference bytes, traced on PC/SC layer: ========= snip =================================== transmitted: 80 C2 00 00 13 D8 00 05 6F 00 C0 4B 4E 7F BD 6D 08 00 04 4D 53 43 4D 02 received: 61 0A transmitted: 00 C0 00 00 0A received: 00 D2 5D 1C 61 C0 00 00 00 05 90 00 ========= snip ===================================
and that is what I got from the serial debug connection (an x marks a match, missing bytes are appended): ========= snip =================================== ... IN=0x00000080 x IN=0x000000c2 x IN=0x00000000 00 IN=0x00000013 x IN=0x000000c2 IN=0x000000d8 x IN=0x00000000 05 IN=0x0000006f 00 IN=0x000000c0 x IN=0x0000004b 4E IN=0x0000007f BD IN=0x0000006d 08 IN=0x00000000 x IN=0x00000004 4D IN=0x00000053 x IN=0x0000004d x IN=0x00000002 x IN=0x00000061 x IN=0x0000000a x IN=0x00000000 x IN=0x000000c0 x IN=0x00000000 00 IN=0x0000000a x IN=0x000000c0 IN=0x00000000 x IN=0x000000d2 5D IN=0x0000001c 61 IN=0x000000c0 x IN=0x00000000 x IN=0x00000000 x IN=0x00000005 x IN=0x00000090 x IN=0x00000000 x WRAP DURING APPEND __pio_irq_demux(43): PIO_ISR_STATUS = 0x11e004d6 RST computed Fi(1) Di(1) ratio: 372 __pio_irq_demux(43): PIO_ISR_STATUS = 0x11800494 RST ========= snip ===================================
Result: a.) There are several missing bytes. b.) There are two bytes (“C2” and “C0”) too much???
My debug serial connection is at a very slow rate (115200Bps) compared to the smart card communication. So I assume it is to be expected, that I’m missing here some bytes ...
Where would be a better way to dump the bytes without interfering / disturbing too much ....
Grateful for any suggestions
Myonium wrote:
Where would be a better way to dump the bytes without interfering / disturbing too much ....
Grateful for any suggestions
Reserve a buffer in RAM on the microcontroller big enough to hold the two first USB transfers and some 100 bytes extra. Fill the buffer where you now do the debug print. Send buffer as ASCII over UART when it has filled up. Compare with output from the usbmon tool. (Use %02x format string.)
//Peter
-
Harald Welte -
Holger Hans Peter Freyther -
Myonium -
Peter Stuge -
Sylvain Munaut