Re: [AVaRICE-user] EDBG/ATATMEL-ICE support

[Philip M. <in...@bi...>]

OK,
The response of the Sam D20 is of course correct (d'Oh!), BTW, I have 
tried this board with OpenOCD and it's fine. I'm on Windows 7, compiling 
under Cygwin.
The 500ms delay was actually changed to 900ms and not *19 (like the 
others). I redid the test with 5000ms, and now we get a different 
response when using -d:
>
> D:\Dropbox\avarice>avarice.exe -4 -d :4242
> AVaRICE version 2.13svn20160229, Mar  6 2016 00:46:22
>
> Defaulting JTAG bitrate to 250 kHz.
>
> Found HID PID:VID 0x03eb:0x2145Probing for HID max. packet size
> Setting max. packet size to 64 from DAP_Info
> JTAG config starting.HID thread started
>
> command "sign-on" [0x01, 0x10]
> 0E 00 00 00 01 10 00
> Received 0x81 0x11 0x00 0x06 0x0e 0x00
> read:  0e 00 00 01 80 00
>
> Got message seqno 0 (command_sequence == 0)
> response: 01 80 00
>
> command "get info (serial number)" [0x00, 0x00]
> 0E 00 01 00 00 00 00 81
> Received 0x81 0x11 0x00 0x1a 0x0e 0x01
> read:  0e 01 00 00 81 00 41 54 4d 4c 32 32 32 32 30 35 30 32 30 30 30 
> 30 33 36 33 ff
>
> Got message seqno 1 (command_sequence == 1)
> response: 00 81 00 41 54 4D 4C 32 32 32 32 30 35 30 32 30 30 30 30 33 
> 36 33 FF
> Found a device, serial number: ATML222205020000363▒
>
> command "get parameter" [0x01, 0x02]
> 0E 00 02 00 01 02 00 00 00 05
> Received 0x81 0x11 0x00 0x0c 0x0e 0x02
> read:  0e 02 00 01 84 01 00 01 04 3b 00 00
>
> Got message seqno 2 (command_sequence == 2)
> response: 01 84 01 00 01 04 3B 00 00
> ICE hardware version: 0
> ICE firmware version: 1.04 (rel. 59)
>
> command "set parameter" [0x12, 0x01]
> 0E 00 03 00 12 01 00 00 00 01 02
> Received 0x81 0x11 0x00 0x06 0x0e 0x03
> read() timed out
> set paramater command failed: JTAG ICE timeout exception
> initJtagBox() failed: JTAG ICE timeout exception
>
> command "sign-off" [0x01, 0x11]
> 0E 00 03 00 01 11 00
> unexpected message size from pipe: 301990670
>
> command "sign-off" [0x01, 0x11]
> 0E 00 03 00 01 11 00
> Received 0x81 0x11 0x00 0x06 0x0e 0x03
> unexpected message size from pipe: 393344
>
> command "sign-off" [0x01, 0x11]
> 0E 00 03 00 01 11 00
> unexpected message size from pipe: 51249152
>
> command "sign-off" [0x01, 0x11]
> 0E 00 03 00 01 11 00
> Received 0x81 0x11 0x00 0x06 0x0e 0x03
> unexpected message size from pipe: 8388864
>
> command "sign-off" [0x01, 0x11]
> 0E 00 03 00 01 11 00
> read:  0e 03 00 01 80 00
>
> Got message seqno 3 (command_sequence == 3)
> Received 0x81 0x11 0x00 0x06 0x0e 0x03
> response: 01 80 00
>
> D:\Dropbox\avarice>

On 06.03.2016 12:05, Joerg Wunsch wrote:
> As Philip Mulrane wrote:
>
>> In jtag2usb.cc I changed all hid_read_timeout() calls (I assume this is
>> what you meant), increasing the timeout parameter by a factor of 10.
> Ah, yes, of course, hid_read_timeout().  Actually, only one call
> matters here, the one inside the (fragment reassembly) loop after
>
> // Query response
>
> The timeout there is currently 500 ms, which I thought ought to be
> enough, even for things like writing flash pages (which currently
> doesn't work for debugWIRE targets, not even in AVRDUDE – I don't
> know what I'm doing wrong by now).
>
>> The
>> output (-d) looked identical, same error.
> This is quite strange, because apparently, in your original mail, the
> next query for an event (which is always being polled while no command
> request is being worked on) yielded the command response:
>
>> command "AVR sign-on" [0x12, 0x10]
>> 0E 00 06 00 12 10 00 00
>> Querying for response: hid_read() failed (0)
>> Querying for event: unexpected response (0x81)
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> So why does it not arrive at the point where we are asking for it?
>
> Is this on Linux?  Perhaps you could trace the underlying USB
> transport using Wireshark there to get an idea what's happening.
>
> We could perhaps turn this into a state machine that correctly
> files the responses received, depending on their ID field (command
> response vs. event respsonse), but I'd like to try keeps simple if
> possible.  We first have to understand why it's not working in the
> first place.
>
> If you completely fail, I'd kindly ask you for getting me your board
> (I could get you one of mine in exchange, Atmel kindly sponsored me
> some XplainedMini so I could develop AVRDUDE for them).  I've got an
> USB analyzer here, perhaps that helps debugging.
>
>> I also tried with a Sam D20
>> xplained pro, and it fails also, but it fails more or less immediately.
>> This is the output of -d (for the Sam d20):
>>> command "AVR sign-on" [0x12, 0x10]
>>> 0E 00 06 00 12 10 00 00
>>> Received 0x81 0x11 0x00 0x07 0x0e 0x06
>>> read:  0e 06 00 12 a0 00 20
>>>
>>> Got message seqno 6 (command_sequence == 6)
>>> response: 12 A0 00 20
>>> initJtagBox() failed: no answer from target
> Here, the response arrives without any problems within
> those 500 ms timeout.  It's just that the response (in
> essence) tells you that the target does not respond since
> it is not an AVR, but you're trying to talk to it as an AVR
> device.  So, this is expected behaviour.