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(a)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(a)gmail.com>wrote;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(a)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(a)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(a)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(a)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(a)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(a)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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>