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 I recently worked on the firmware again and believe I have fixed the issues with the parity errors (at least for my SGS 2 and SGS 4 with ATT 4G/LTE cards) Can you try the attached firmware and let me know your results? Thanks On Mon, Mar 10, 2014 at 8:23 AM, Min Xu <mxu at sanjole.com> wrote: > Hi 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/20140624/a17d1070/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: main_simtrace.bin Type: application/octet-stream Size: 22908 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/simtrace/attachments/20140624/a17d1070/attachment.bin>