<div dir="ltr">Hi Dean<br><br>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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 10, 2014 at 5:19 AM, Dean Chester <span dir="ltr"><<a href="mailto:dean.g.chester@gmail.com" target="_blank">dean.g.chester@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Min, <div><br></div><div>Finally my debug cable arrived, I have some debug output for the card that fails to successfully read the ATR: </div>
<div><br></div><div><div>[000033] Heart beat 00000007</div><div>
[000034] Heart beat 00000008</div><div>[000035] VCC_PHONE on</div><div>[000036] RST</div><div>[000037] computed Fi(1) Di(1) ratio: 372</div><div>[000038] UART parity error: 2</div><div>[000039] USBT(D=002011A8, S=0002, L=0026, P=00) H4/T4: E7 9A 03 1F / 67 42 70 02</div>
<div>[00003A] UART parity error: 3</div><div>[00003B] Heart beat 00000009</div><div>[00003C] UART parity error: 4</div><div>[00003D] UART parity error: 5</div><div>[00003E] UART parity error: 6</div><div>[00003F] UART parity error: 7</div>
<div>[000040] UART parity error: 8</div><div>[000041] UART parity error: 9</div><div>[000042] UART parity error: 10</div><div>[000043] UART parity error: 11</div><div>[000044] UART parity error: 12</div><div>[000045] UART parity error: 13</div>
<div>[000046] UART parity error: 14</div><div>[000047] UART parity error: 15</div><div>[000048] UART parity error: 16</div><div>[000049] UART parity error: 17</div><div>[00004A] UART parity error: 18</div><div>[00004B] UART parity error: 19</div>
<div>[00004C] UART parity error: 20</div><div>[00004D] UART parity error: 21</div><div>[00004E] UART parity error: 22</div><div>[00004F] UART parity error: 23</div><div>[000050] UART parity error: 24</div><div>[000051] Heart beat 0000000A</div>
<div>[000052] UART parity error: 25</div><div>[000053] UART parity error: 26</div><div>[000054] UART parity error: 27</div><div>[000055] UART parity error: 28</div><div>[000056] UART parity error: 29</div><div>[000057] UART parity error: 30</div>
<div>[000058] UART parity error: 31</div><div>[000059] UART parity error: 32</div><div>[00005A] UART parity error: 33</div><div>[00005B] UART parity error: 34</div><div>[00005C] UART parity error: 35</div><div>[00005D] UART parity error: 36</div>
<div>[00005E] UART parity error: 37</div><div>[00005F] UART parity error: 38</div><div>[000060] UART parity error: 39</div><div>[000061] UART parity error: 40</div><div>[000062] UART parity error: 41</div><div>[000063] UART parity error: 42</div>
<div>[000064] UART parity error: 43</div><div>[000065] UART parity error: 44</div><div>[000066] UART parity error: 45</div><div>[000067] UART parity error: 46</div><div>[000068] UART parity error: 47</div><div>[000069] Heart beat 0000000B</div>
<div>[00006A] Heart beat 0000000C</div><div>[00006B] UART parity error: 48</div><div>[00006C] UART parity error: 49</div><div>[00006D] UART parity error: 50</div><div>[00006E] UART parity error: 51</div><div>[00006F] UART parity error: 52</div>
<div>[000070] UART parity error: 53</div><div>[000071] UART parity error: 54</div><div>[000072] UART parity error: 55</div><div>[000073] UART parity error: 56</div><div>[000074] UART parity error: 57</div><div>[000075] UART parity error: 58</div>
<div>[000076] UART parity error: 59</div><div>[000077] Heart beat 0000000D</div><div>[000078] UART parity error: 60</div><div>[000079] UART parity error: 61</div><div>[00007A] UART parity error: 62</div><div>[00007B] UART parity error: 63</div>
<div>[00007C] UART parity error: 64</div><div>[00007D] UART parity error: 65</div><div>[00007E] UART parity error: 66</div><div>[00007F] UART parity error: 67</div><div>[000080] Heart beat 0000000E</div><div><br></div></div>
<div><br></div><div>So any ideas where this error is being created with your firmware?</div><div><br></div><div>Kind Regards,</div><div><br></div><div>Dean Chester</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra">
<br><br><div class="gmail_quote">
On 22 February 2014 15:28, Dean Chester <span dir="ltr"><<a href="mailto:dean.g.chester@gmail.com" target="_blank">dean.g.chester@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Min, <div><br></div><div>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.</div>
<div><br></div><div>I've also not been able to apply your patches correctly to work out where the error might be occurring in your modifications. </div><div><br></div><div>Kind Regards, </div><span><font color="#888888"><div>
<br></div><div>Dean Chester</div>
</font></span></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On 4 February 2014 19:10, Min Xu <span dir="ltr"><<a href="mailto:mxu@sanjole.com" target="_blank">mxu@sanjole.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div><div>Hi Dean<br><br></div>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.<br>
<br></div>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... )<br><br></div>Try get a serial cable plugged into the simtrace board, and capture the debug output to see if parity error were seen.<br>
<br></div>Best regards<br><div><div><div><br><br></div></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Feb 2, 2014 at 4:40 AM, Dean Chester <span dir="ltr"><<a href="mailto:dean.g.chester@gmail.com" target="_blank">dean.g.chester@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Min, <div><br></div><div>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: </div>
<div><br></div><div><div>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</div><div>01 00 01 01 02 00 00 00 0f 00 00 00 00 00 00<br></div><div>01 00 01 01 03 00 00 00 12 00 00 00 00 00 00 00 00 00</div>
<div><br></div><div>And the ATR should look like: </div><div><br></div><div><div>3B 9F 96 80 1F C7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 </div><div><br></div></div><div>And with the same card from the same company I got: </div>
<div><br></div><div><div><div>01 01 01 01 01 00 00 00 16 00 9f 96 80 1f c7 80 31 00 00 00 00 00 </div><div>01 00 01 01 02 00 00 00 13 00 67 42 70 02 10 00 00 01 f9</div><div>01 00 01 01 03 00 00 00 12 00 ff 10 96 79 ff 10 96 79</div>
</div><div><br></div></div><div>With the card I had success with I got the following input in: </div><div><br></div><div><div>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</div>
</div><div><br></div><div>And the ATR looks like: </div><div>3b 9f 96 80 1f c7 80 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br></div><div><br></div><div>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.</div>
<div><br></div><div>Kind Regards, </div><span><font color="#888888"><div><br></div><div>Dean Chester</div></font></span></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 30 January 2014 21:47, Min Xu <span dir="ltr"><<a href="mailto:mxu@sanjole.com" target="_blank">mxu@sanjole.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>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.<br>
<br></div>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.<br>
<br></div>Best Regards<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 6:21 AM, Dean Chester <span dir="ltr"><<a href="mailto:dean.g.chester@gmail.com" target="_blank">dean.g.chester@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">It was mostly the lost bytes/scrambled data with a variety of handsets that i'd tested with, compared with ubuntu running natively. <span><font color="#888888"><div>
<br></div><div>Dean</div></font></span></div><div><div><div class="gmail_extra"><br>
<br><div class="gmail_quote">On 27 January 2014 18:37, Min Xu <span dir="ltr"><<a href="mailto:mxu@sanjole.com" target="_blank">mxu@sanjole.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">P.S. What problems were you experiencing of it running in a virtualized system, can you elaborate?<br><br>Thanks<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jan 27, 2014 at 8:36 AM, Min Xu <span dir="ltr"><<a href="mailto:mxu@sanjole.com" target="_blank">mxu@sanjole.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br>
<br></div>Best Regards<br></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Jan 27, 2014 at 1:05 AM, Dean Chester <span dir="ltr"><<a href="mailto:dean.g.chester@gmail.com" target="_blank">dean.g.chester@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Thanks Min it works a treat it also fixes the issues running in a virtualised environment which I do for Ubuntu. <div><br></div><div>Is your new firmware under the same licence as the original?</div><div>
<br></div><div>Kind Regards, </div><div><br></div><div>Dean Chester</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 January 2014 21:55, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se" target="_blank">peter@stuge.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Min Xu wrote:<br>
> I would be happy to send them the USB protocol changes. However,<br>
> it will be INCOMPATIBLE with earlier firmware based SIMTrace boards.<br>
<br>
</div></div>There is a standardised way to deal with protocol changes in USB;<br>
change either the bDeviceProtocol field in the device descriptor or<br>
the bInterfaceProtocol field in the interface descriptor, and make<br>
host software do the appropriate thing based on the descriptors of<br>
the connected device.<br>
<br>
Of course only new host software will work with the new protocol, but<br>
this way new host software still continues to work with the old protocol.<br>
<span><font color="#888888"><br>
<br>
//Peter<br>
<br>
</font></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>