Trace Debugging SAMD51

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

Hi have a SAMD51 circuit that seems to be freezing and rebooting rather at random times due to WDT firing. 

I have even placed early interrupt in WDT configuration and can confirm that when I place a while() in my code, I do see the early interrupt fire and print debug messages.

 

However when this special freezing even happens (not the while loop I just mentioned), this WDT early interrupt never fires. Even if I run the code in debug by pressing the play button and the fault occurs, AtmelStudio does not even know about the fault, it happily waits in this debug state... you would think that AtmelStudio would capture the fault location and jump to it, like it happens when say if CPU got stuck in a loop and rebooted due to WDT firing.

It is mind blowing, have spent several hours trying to go over code, cant see any issues.

 

I use Atmel-ICE for my programming and debug. I remember with SAMD21 there was micro trace buffer option which would let me see what functions are being hit etc.

I cant seem to be able to do this with SAMD51??? I do see in datasheet there is the ETB option. How do I enable it and view what functions (or even PC/Stack pointers) are being hit?

 

Would anyone be able to advise? It would be really useful, thanks.

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

You probably want something like a Segger J-trace. Just be sitting down when you see the price.

 

How about the hardware - is that correct? Dodgy pcb design etc can cause some weird issues.

 

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

Hoping not to have to buy any new debugger. I would have thought Atmel-ICE was able to debug using SWD port...

I just need something similar that we see in SAMD2x M0+ with MTB and Trace Program Counter in Atmel Studio ... it shows all the functions/areas in code being hit.

It seems ETB in SAMD5 should be able to achieve something similar...

So far I have done the following:

 

1) Enable ETB mapping to first part of 32KB SRAM, by doing DSU->CFG.reg |= DSU_CFG_ETBRAMEN

2) Made sure I have the .relocate=0x20008000 is defined in Atmel Studio projet properties Toolchain Tab: ARM/GNU Linker -> Memory Settings and under SRAM segment.

 

But still when I go to Debug -> Windows -> Program Counter Trace, nothing is captured. What am I missing?

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

luvocean1 wrote:
I would have thought Atmel-ICE was able to debug using SWD port...

It can - but that doesn't (necessarily) support Trace.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Studio does not support ETB/ETM

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Wed. Nov 11, 2020 - 01:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok so Atmel-ICE does not support trace capability for sure? I think it does ITM trance using SWO pin?

But I wish to use the ETB as I have used up the 64pin package is not suitable for SW0 pin (or in use).

 

If Studio does not support ETB....is there anything else I can use?

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

You can always turn on the ETB in your app, and decode the resulting memory yourself... Studio supports debug scripts in python that could decode on halt... But there's no built in Studio support.
.
Or, use a IDE that supports ETB... Any of them should work with the Atmel-ICE...

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

Last Edited: Mon. Nov 16, 2020 - 01:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That seems like a good idea.

Can you suggest any links / guides?

 

Which other IDEs would support Atmel-ICE? So Atmel-ICE is capable of ETB sniffing? Does it need the SWO pin for this or just SWDIO/CLK pins are sufficient for this?

 

 

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

The B in ETB means buffer, meaning that the trace data ends up in a block in RAM instead of being emitted on the trace port (SWO and PTrace), so any debugger with memory access can deal with ETB.
.
Atmel-ICE is a CMSIS-DAP compliant debugger, so any IDE that supports CMSIS-DAP debuggers should be able to drive the Atmel-ICE.
.
No, no links...

:: Morten

 

(yes, I work for Microchip, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

SEGGER Ozone might work and has an evaluation (multi-platform)

VisualGDB has tracing and has a thirty day trial period.

 

Tracing on Atmel ATSAMD51 - SEGGER Wiki

VisualGDB - Serious cross-platform support for Visual Studio

 

"Dare to be naïve." - Buckminster Fuller

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

luvocean1 wrote:
It is mind blowing, have spent several hours trying to go over code, cant see any issues.
That's the price range for linters (effort * billing rate); linters have some capability to detect ambiguities, imprecision, possible off-by-one, etc.

The month range may make a static analyzer a value; expensive though there's zero price static analysis (if willing for a paradigm change, attributes into code though the attributes can be removed for final test)

Code review is an excellent value; a coding standard aids.

luvocean1 wrote:
(or even PC/Stack pointers)
The CPU can catch a stack overflow.

 


Inexpensive Firmware Process Improvements for Small Teams - Barr Group

Tag - sound - Frama-C news and ideas (sound static analysis is expensive though unsound is still a value)

SEI CERT C Coding Standard - SEI CERT C Coding Standard - Confluence

 

Are We Shooting Ourselves in the Foot with Stack Overflow? « State Space

 

"Dare to be naïve." - Buckminster Fuller

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

Here is some more finding...

I have managed to reproduce this problem readily now. The issue happens only after power is lost to board and power is brought back very quickly. The CPU obviously keeps spinning until the voltage dips too low.

But something happens in code when voltage too low. It corrupts the CPU somehow. When the power is back and it goes past certain segment of the code, the CPU hangs and WDT resets it.

 

After I reflash the CPU, all is well and problem does not happen.

 

So what is the difference between a Reflash of controller using Atmel ICE (which also resets it) as opposed to reset triggered WDT timeout?

WDT reset obviously does not clear something (RAM variables)?

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

luvocean1 wrote:
something happens in code when voltage too low.

"too low" means you're running out of spec - so the behaviour is undefined.

That's what a brownout detector is for.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

luvocean1 wrote:
After I reflash the CPU, all is well and problem does not happen

What about doing a full power cycle ?

 

luvocean1 wrote:
WDT reset obviously does not clear something (RAM variables)?

A Reset (by ICE or by WDT) won't clear any RAM that's unaffected by the 'C' startup.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

luvocean1 wrote:
After I reflash the CPU, all is well and problem does not happen

What about doing a full power cycle ?

 

luvocean1 wrote:
WDT reset obviously does not clear something (RAM variables)?

A Reset (by ICE or by WDT) won't clear any RAM that's unaffected by the 'C' startup.

 

So which type of resets will call C startup?

I will double check with full hardware power cycle.

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

luvocean1 wrote:
which type of resets will call C startup?

all of them; including anything that just jumps to the entry point - even without a reset.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

luvocean1 wrote:

Hoping not to have to buy any new debugger. I would have thought Atmel-ICE was able to debug using SWD port...

I just need something similar that we see in SAMD2x M0+ with MTB and Trace Program Counter in Atmel Studio ... it shows all the functions/areas in code being hit.

It seems ETB in SAMD5 should be able to achieve something similar...

So far I have done the following:

 

1) Enable ETB mapping to first part of 32KB SRAM, by doing DSU->CFG.reg |= DSU_CFG_ETBRAMEN

2) Made sure I have the .relocate=0x20008000 is defined in Atmel Studio projet properties Toolchain Tab: ARM/GNU Linker -> Memory Settings and under SRAM segment.

 

But still when I go to Debug -> Windows -> Program Counter Trace, nothing is captured. What am I missing?

 

Does anybody know the difference between using .relocate to move RAM usage to start from 0x20008000 as opposed to updating the bolded line in in this file: samd51j20a_flash.ld

MEMORY
{
  rom      (rx)  : ORIGIN = 0x00010000, LENGTH = 0x000F0000
  ram      (rwx) : ORIGIN = 0x20008000, LENGTH = 0x0003800
  bkupram  (rwx) : ORIGIN = 0x47000000, LENGTH = 0x00002000
  qspi     (rwx) : ORIGIN = 0x04000000, LENGTH = 0x01000000
}

 

or also in samd51j20a_sram:

MEMORY
{
  ram      (rwx) : ORIGIN = 0x20008000, LENGTH = 0x00038000
  bkupram  (rwx) : ORIGIN = 0x47000000, LENGTH = 0x00002000
  qspi     (rwx) : ORIGIN = 0x04000000, LENGTH = 0x01000000
}

 

Whats the difference?

And why is there RAM entry in flash.ld and also in sram.ld files? Do we need to mod both files?

Datasheet says first 32KB is used when we turn on ETB debug.

Do I need to do anything other than the two steps above?