This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/simtrace@lists.osmocom.org/.
Min Xu mxu at sanjole.comHi Dean As far as I know, I made no changes to modify the usart/iso7816 communication parameters. I have seen parity errors like this, and got improved result when I can make sure the flat ribbon cable is not folded over on itself. The parity error is reported by the usart peripheral, which is supposed to provide 1 character at a time to the main software code. I will check the changes again. On Mon, Mar 10, 2014 at 5:19 AM, Dean Chester <dean.g.chester at gmail.com>wrote: > Hi Min, > > Finally my debug cable arrived, I have some debug output for the card that > fails to successfully read the ATR: > > [000033] Heart beat 00000007 > [000034] Heart beat 00000008 > [000035] VCC_PHONE on > [000036] RST > [000037] computed Fi(1) Di(1) ratio: 372 > [000038] UART parity error: 2 > [000039] USBT(D=002011A8, S=0002, L=0026, P=00) H4/T4: E7 9A 03 1F / 67 42 > 70 02 > [00003A] UART parity error: 3 > [00003B] Heart beat 00000009 > [00003C] UART parity error: 4 > [00003D] UART parity error: 5 > [00003E] UART parity error: 6 > [00003F] UART parity error: 7 > [000040] UART parity error: 8 > [000041] UART parity error: 9 > [000042] UART parity error: 10 > [000043] UART parity error: 11 > [000044] UART parity error: 12 > [000045] UART parity error: 13 > [000046] UART parity error: 14 > [000047] UART parity error: 15 > [000048] UART parity error: 16 > [000049] UART parity error: 17 > [00004A] UART parity error: 18 > [00004B] UART parity error: 19 > [00004C] UART parity error: 20 > [00004D] UART parity error: 21 > [00004E] UART parity error: 22 > [00004F] UART parity error: 23 > [000050] UART parity error: 24 > [000051] Heart beat 0000000A > [000052] UART parity error: 25 > [000053] UART parity error: 26 > [000054] UART parity error: 27 > [000055] UART parity error: 28 > [000056] UART parity error: 29 > [000057] UART parity error: 30 > [000058] UART parity error: 31 > [000059] UART parity error: 32 > [00005A] UART parity error: 33 > [00005B] UART parity error: 34 > [00005C] UART parity error: 35 > [00005D] UART parity error: 36 > [00005E] UART parity error: 37 > [00005F] UART parity error: 38 > [000060] UART parity error: 39 > [000061] UART parity error: 40 > [000062] UART parity error: 41 > [000063] UART parity error: 42 > [000064] UART parity error: 43 > [000065] UART parity error: 44 > [000066] UART parity error: 45 > [000067] UART parity error: 46 > [000068] UART parity error: 47 > [000069] Heart beat 0000000B > [00006A] Heart beat 0000000C > [00006B] UART parity error: 48 > [00006C] UART parity error: 49 > [00006D] UART parity error: 50 > [00006E] UART parity error: 51 > [00006F] UART parity error: 52 > [000070] UART parity error: 53 > [000071] UART parity error: 54 > [000072] UART parity error: 55 > [000073] UART parity error: 56 > [000074] UART parity error: 57 > [000075] UART parity error: 58 > [000076] UART parity error: 59 > [000077] Heart beat 0000000D > [000078] UART parity error: 60 > [000079] UART parity error: 61 > [00007A] UART parity error: 62 > [00007B] UART parity error: 63 > [00007C] UART parity error: 64 > [00007D] UART parity error: 65 > [00007E] UART parity error: 66 > [00007F] UART parity error: 67 > [000080] Heart beat 0000000E > > > So any ideas where this error is being created with your firmware? > > Kind Regards, > > Dean Chester > > > On 22 February 2014 15:28, Dean Chester <dean.g.chester at gmail.com> wrote: > >> Hi Min, >> >> Sorry for the slow response had a lot of work on. I do not have a debug >> cable. However it I have just tried this problematic card with V0.5 >> firmware off the wiki and it obtains the ATR correctly. The error isn't >> happening because of a issue with the cable being bent, I know this as I >> have tried it in all orientations to see if this was the case. >> >> I've also not been able to apply your patches correctly to work out where >> the error might be occurring in your modifications. >> >> Kind Regards, >> >> Dean Chester >> >> >> On 4 February 2014 19:10, Min Xu <mxu at sanjole.com> wrote: >> >>> Hi Dean >>> >>> I believe that you are seeing incomplete or partial (maybe even) ATRs. >>> I believe I experienced something similar when I see parity error in the >>> debug messages (from the debug port). The first byte of the ATR must be 3F >>> or 3B. I believe the firmware code I currently have should NOT break and >>> ATR into multiple segments. Besides, ATRs are transmitted in a single >>> frame, so there would not be an idle time to push out the partial ATR into >>> the USB transmit buffer. >>> >>> So I believe you are having similar problem that I experienced when the >>> ribbon cable is twisted, or bent close together like a U (which might have >>> caused interference... ) >>> >>> Try get a serial cable plugged into the simtrace board, and capture the >>> debug output to see if parity error were seen. >>> >>> Best regards >>> >>> >>> >>> >>> On Sun, Feb 2, 2014 at 4:40 AM, Dean Chester <dean.g.chester at gmail.com>wrote: >>> >>>> Hi Min, >>>> >>>> I've just been using the new firmware with a different type of sim card >>>> and noticed that the ATR is scrambled, at least for the header of the ATR. >>>> The ATR is the same length as the one I had great success with. The cards >>>> are running at the same speed according to the ATRs however the new card >>>> seems to send it's ATR over 3 commands not just one. Whats also interesting >>>> is the ATR scrambling is different. Here is an example with the Simtrace >>>> Header attached: >>>> >>>> 01 01 01 01 01 00 00 00 1a 00 e7 9a 03 1f c7 80 31 00 00 00 00 00 00 00 >>>> 00 00 >>>> 01 00 01 01 02 00 00 00 0f 00 00 00 00 00 00 >>>> 01 00 01 01 03 00 00 00 12 00 00 00 00 00 00 00 00 00 >>>> >>>> And the ATR should look like: >>>> >>>> 3B 9F 96 80 1F C7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> >>>> And with the same card from the same company I got: >>>> >>>> 01 01 01 01 01 00 00 00 16 00 9f 96 80 1f c7 80 31 00 00 00 00 00 >>>> 01 00 01 01 02 00 00 00 13 00 67 42 70 02 10 00 00 01 f9 >>>> 01 00 01 01 03 00 00 00 12 00 ff 10 96 79 ff 10 96 79 >>>> >>>> With the card I had success with I got the following input in: >>>> >>>> 01 01 01 01 01 00 00 00 20 00 3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 >>>> 00 00 00 00 00 00 00 00 >>>> >>>> And the ATR looks like: >>>> 3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>> >>>> Any ideas where these errors are coming from in the firmware. I notice >>>> that the lengths in the failed are equal to 3B which is the start of the >>>> ATR if thats of any help. The tests were done with the same phone connected >>>> to the tracer just swapping the sim cards. >>>> >>>> Kind Regards, >>>> >>>> Dean Chester >>>> >>>> >>>> On 30 January 2014 21:47, Min Xu <mxu at sanjole.com> wrote: >>>> >>>>> That does make sense to me since I had issues where before I changed >>>>> the usb header, the host was sometimes merging multiple req_ctx into a >>>>> single usb read. >>>>> >>>>> I am attaching a tar.gz file containing all my changes as separate git >>>>> commits / format-patches and hopefully it will get committed to the >>>>> repository. This includes the latest change to the usb header as well as a >>>>> change (as Peter suggested) to the bDeviceProtocol in >>>>> usb_descriptors_openpcd.h, setting the new value to 0. >>>>> >>>>> Best Regards >>>>> >>>>> >>>>> On Thu, Jan 30, 2014 at 6:21 AM, Dean Chester < >>>>> dean.g.chester at gmail.com> wrote: >>>>> >>>>>> It was mostly the lost bytes/scrambled data with a variety of >>>>>> handsets that i'd tested with, compared with ubuntu running natively. >>>>>> >>>>>> Dean >>>>>> >>>>>> >>>>>> On 27 January 2014 18:37, Min Xu <mxu at sanjole.com> wrote: >>>>>> >>>>>>> P.S. What problems were you experiencing of it running in a >>>>>>> virtualized system, can you elaborate? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> >>>>>>> On Mon, Jan 27, 2014 at 8:36 AM, Min Xu <mxu at sanjole.com> wrote: >>>>>>> >>>>>>>> I am contributing it to the project. Once I incorporate Peter >>>>>>>> Stuge's suggestion, hopefully within the next few weeks I will submit >>>>>>>> another commit. >>>>>>>> >>>>>>>> Best Regards >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Jan 27, 2014 at 1:05 AM, Dean Chester < >>>>>>>> dean.g.chester at gmail.com> wrote: >>>>>>>> >>>>>>>>> Thanks Min it works a treat it also fixes the issues running in a >>>>>>>>> virtualised environment which I do for Ubuntu. >>>>>>>>> >>>>>>>>> Is your new firmware under the same licence as the original? >>>>>>>>> >>>>>>>>> Kind Regards, >>>>>>>>> >>>>>>>>> Dean Chester >>>>>>>>> >>>>>>>>> >>>>>>>>> On 24 January 2014 21:55, Peter Stuge <peter at stuge.se> wrote: >>>>>>>>> >>>>>>>>>> Min Xu wrote: >>>>>>>>>> > I would be happy to send them the USB protocol changes. >>>>>>>>>> However, >>>>>>>>>> > it will be INCOMPATIBLE with earlier firmware based SIMTrace >>>>>>>>>> boards. >>>>>>>>>> >>>>>>>>>> There is a standardised way to deal with protocol changes in USB; >>>>>>>>>> change either the bDeviceProtocol field in the device descriptor >>>>>>>>>> or >>>>>>>>>> the bInterfaceProtocol field in the interface descriptor, and make >>>>>>>>>> host software do the appropriate thing based on the descriptors of >>>>>>>>>> the connected device. >>>>>>>>>> >>>>>>>>>> Of course only new host software will work with the new protocol, >>>>>>>>>> but >>>>>>>>>> this way new host software still continues to work with the old >>>>>>>>>> protocol. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> //Peter >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20140310/0ab12076/attachment.htm>