ICE3 Debugging hangs

Go To Last Post
18 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi gang,

I'm debugging a source for a Mega32A. The CPU runs with 8MHz internal clock. The ICE3 is attached and the ICE clock is 1.99MHz. Sometimes it happens that a single step in AS6 does not return. My normal handling is:
press F11 (or F10) and wait for the cursor to skip.
If the problem occurs you wait for ages, a timeout window appears requesting to wait for another minute or to cancel waiting. Pressing the one or other button does not recover. Disconnecting the USB cable makes AS6 dialogues free, but any next debbuging command (Start,...) hangs again.
The only solution to recover to normal debugging is to power-off the target (which also removes power from the ICE 3).

Any suggestions?
Cheers,
Knut

PC: Win 7 -64,
AS: 6.0.1938 -SP 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

the ICE clock is 1.99MHz

That sounds too fast. I know the limit is 1/4 but that's very close.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi clawson,

clawson wrote:
Quote:

the ICE clock is 1.99MHz

That sounds too fast. I know the limit is 1/4 but that's very close.

thanks for the advice. When involved to a problem it's good to have someone with an external view.
I've set the Jtag Clock to 1.80MHz and on the first glance it seems to work more stable. Therefore 1/4 - several% seems to be a more valid speed :evil:

Cheers,
Knut

ps: 2 hours later I'm down to 1MHz and now it is geting worse. For more than one hour debugging was okay and now I'm back to the point were a breakpoint is entered and after pressing of F5 the flashing green LED on the ICE3 goes off and AS6 behaves as described in my first mail. I restarted AS6, recompiled the whole program and no change - for today I expect it is the best to go to bed... maybe one trial is a full power off reboot of PC and AVR.

But that did not help either. One observation I'll need to add: If the target is powered-off the output window of AS6 shows the "Target power lost" message and the cursor skips to the next breakpoint where it should be - so as if everything is working correctly, except AS6 is unable handle the information from ICE3 properly.

Any idea is welcome.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
If the target is powered-off the output window of AS6 shows the "Target power lost" message
I usually do a "Stop debug" before turning power off/on to the taget board with other debuggers.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
If the target is powered-off the output window of AS6 shows the "Target power lost" message
I usually do a "Stop debug" before turning power off/on to the taget board with other debuggers.
John,

agreed if you want to stop debugging (we had that issue a while ago), but at my special case AS6 does not accept any input. So dropping the target power releases the dialogue of AS6. At least I want to continue debugging and not stopping the debugging. So target power-off is a kind of emergency exit...

Cheers,
Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but at my special case AS6 does not accept any input.
This is WITHOUT turning the power off to the target?

I understood that you turned the power off to the target for some reason and then AS6 hangs which would be reasonable I guess if the debug session was not stopped first, that was the reason for my comment.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
but at my special case AS6 does not accept any input.
This is WITHOUT turning the power off to the target?
Hi John,

no, reaching a breakpoint I press F5 / F10 / F11 (one of them) and now AS6 hangs. LEDs on ICE3 looks as if it has reached the next breakpoint. AS6 does not accept any input and after a while a timeout window appears. NOW I switch off the target power and AS6 response with a power-off message and reacts on dialogues. The cursor jumps to the next breakpoint. (I'm not sure if the last happens at this time, because I repower very quickly).

I think it will be the best to move the whole environment to a M$-VM under Linux and trace the USB channel. :x
Cheers,
Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi all,

I have exactly the same problem. Atxmega32A4U, ICE3, Win7 32bit, AS 6.0.1938 -SP 1. Debugging often hangs like Knut described before. Debugging is not possible in this way.... Need help!
Thanks
Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Two things I observed:

    1. Pressing on a break point any of the Go-button lights the step LED of ICE3. When it switches off AS6 might responde or not - so it seems to be a problem between ICE3 & AS6.
    2. @Christian how many LOC does the file have were the problem occour? Mine is about 1900 including deactive code (#if 0...#endif)so it could be a matter of size...
Cheers, Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I observed this problems with an ICE2, too.

@Knut: Do you mean only the file where the breakpoint is? It's around 200 LOCs. For the whole project I dont't know the LOCs... Can I get that somewhere in AS6?

Best regards,
Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

poppirs wrote:
@Knut: Do you mean only the file where the breakpoint is? It's around 200 LOCs.
Christian,
thanks, its only about the subroutine. To find similarities: Is it one source file or only one routine were debbuing hangs? If it is only one roeutine: Do you allocate lots of local variables in this routine, so gcc's handling of the "stack-variables" confuses the debugger?

For me it is one special subroutine which does not want to be debugged. Yesterday I tried to assembler single step from the higher level into this routine and while executing the call the debugging hang. If I stop before and jump over (F10) the subroutine works as programmed - so I'm back to printf-debugging, putting interesting variables into globals and think about the results.
Cheers,
Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kschwiRG wrote:
I think it will be the best to move the whole environment to a M$-VM under Linux and trace the USB channel. :x

So here it comes. Another project, another CPU (M1284) same compiler (4.7.2), Studio 6.0.1938 SP1, XP-32 in a VM under Linux. I started the program, ran to a breakpoint and stepped twice with F11 and next F5 and Adios...

Attached you find the trace of Wireshark for this handling and a screen capture of the AS. The breakpoint is located at 0x8990 (for someone looking into the tracedata).

Atmel, any suggestions are welcome.

Cheers,
Knut

ps: Tried it with Toolchain 3.4.0.65 and there is no difference in behaviour....

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried to load your trace data file. While wireshark can handle it,
the displayed data look somewhat suspicious: everything is claimed to
belong to endpoint 0, being isochronous transfers etc. pp. If I
connect a JTAGICE3 to a Linux machine, and ask lsusb about it, I get:

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval              16

So it appears there are two "regular" data endpoints in both
directions (allowsing up to 512 byte transfers on USB2.0 hosts), and
one "special" IN endpoint with a shorter packet size, where the host
is requested to poll the EP each 4.096 seconds. That probably means
this EP is used to transfer data initiated by the ICE without being
requested from the host (what the JTAGICEmkII description calls an
"event"). Wonder why they didn't use an interrupt EP then.

Anyway, it would be fine if the trace data could reflect the correct
endpoints.

Also, it seems there are way too many data in the trace. If I
restrict the display filter to "frame.cap_len > 64", and only look at
the data starting at offset 64, it seems we are looking at the actual
ICE data. It *slightly* resembles the data I'm acquainted with from
JTAGICEmkII, for example:

0040  0e 00 1c 2f 12 21 00 20  5d 00 00 00 03 00 00 00   .../.!.  ].......

answered by

0040  0e 1c 2f 12 84 00 e7 40  21 00                     ../....@ !.      

The "5d" rings a bell: this is the SPL address (in memory address
space), so the following "03" could be a request length, as this would
read SPL, SPH, and SREG in sequence. The response is "0x40e7" for the
stack pointer, and "0x21" for SREG.

The "read memory" command in JTAGICEmkII is very similar, 0x20 is also
MTYPE_SRAM there. Also, the 0x0E "token", identifying the start of
the actual packet data is the same, only that the JTAGICEmkII did have
another framing layer (header + trailing CRC) around that, since it
could also communicate through RS-232.

Two packets before that, a similar command (read memory?) can be
found:

0040  0e 00 1a 2f 12 21 00 20  00 00 00 00 20 00 00 00   .../.!.  .... ...

appears to be answered by

0040  0e 1a 2f 12 84 00 00 00  34 b5 6e d3 5f 6d ef eb   ../..... 4.n._m..
0050  c4 3e ee f7 00 00 26 08  01 00 e0 33 00 00 26 08   .>....&. ...3..&.
0060  c3 35 e7 40 6c 38 00                               .5.@l8.          

Judging by the stackpointer/SREG read above, this would ask for all 32
CPU registers (through their SRAM mapping at address 0), the response
is "00 00 34 b5 6e d3 5f 6d ef eb c4 3e ee f7 00 00 26 08 01 00 e0 33
00 00 26 08 c3 35 e7 40 6c 38". (The last byte transferred is always
0, for whatever reason.)

Between both requests is another one:

0040  0e 00 1b 2f 12 35 00                               .../.5.          

response:

0040  0e 1b 2f 12 83 00 90 89  00 00                     ../..... ..      

You say:

> The breakpoint is located at 0x8990

...and now you can see the 0x8990, so this is probably requesting the
current PC value (measured in 16-bit words, as usual for the AVR).

(For anyone interested in checking the above, the corresponding frame
numbers in Knut's trace are #856, #858, #850, #852, #853, #855).

If you go towards the end of the file, it appears to run in an
infinite (or very long-lasting) loop, reading SRAM addresses 0x40ea (2
bytes), 0x40f6, 0x40f5, 0x40f4, 0x40f3, 0x40f2, 0x40f1, 0x40f0 (1 byte
each), and 0x40f7 (2 bytes). According to the SP value above, these
are located on the stack, so it's probably the local data to the
current function.

Sorry, I don't have the time to look into more detail now. Could you
perhaps figure out how to obtain the trace with the correct USB
endpoint numbers etc.?

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> I tried to load your trace data file. While wireshark can handle it,
> the displayed data look somewhat suspicious: everything is claimed to
> belong to endpoint 0, being isochronous transfers etc. pp.

Nevermind. Seems that Wireshark version was too outdated. Using a different
one, the data make much more sense now.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A couple of things that I found can cause that:

1) USB port is not supplying enough power for the ICE3.
2) Out of memory in the device, so the stack blows up when stepping.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Out of memory in the device, so the stack blows up when stepping.


Are you suggesting that single stepping consumes more stack space in the app than e.g. having the app free-running?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

wires wrote:
1) USB port is not supplying enough power for the ICE3.

Do you think that power consumption depentds on the routine where you set your break point?
Cheers,
Knut

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Do you think that power consumption depentds on the routine where you set your break point?

No.