Problem with Single Step SAME70

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

Hi all,

 

There is a problem with IDE debuggers for SAME70, and as I understand, all
Cortex-M7 core based processors.  With other Cortex controllers, when a
debbuger pauses or hits a breakpoint, the debugger stops interrupt processing
so that, even if interrupts are running in the system, when you single step,
you go to the next line in the software module you are debugging.
With the M7 debuggers, like GDB which is used by Atmel Studio, when you hit a
breakpoint and then try to single step, if any interrupts are running in the
system, you step into an ISR, or the same instruction, not your next instruction
and will keep doing this forever.  The "workaraound" is apparently to put your
cursor on another line and tell the debugger to "Run to Cursor".  But even this
does not work until you disable the breakpoint where you stopped, because the
interrupt return keeps taking you back to the breakpoint rather than going on.

 

Does anyone know if this is being fixed?  Or if there is a workaround?
Or if any toolsets have fixed it?  I have been working on a complex application
and this bug makes it really painful to just operate.

 

My setup:
- custom board with ATSAME70N21
- Atmel Studio v7.0.1417
- Atmel-ICE as debugger tool (SWD interface)
 

Help?

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

Hello,

 

Did you ever find a solution to this problem?

 

I am experiencing the same thing and it's a bit of a problem trying to single step/debug this section of code. Even the "workaround" you suggest doesn't always help.

 

I have the same Studio 7 version you mentioned.

Debugger is the EDBG chip on the SAME70 Explained board. I'm sure it will be the same issue on our target board which uses the Atmel ICE.

SAME70Q21

 

This is the only article I could find describing the problem I have.

 

Thanks.
 

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

This is rooted in a core issue in the Cortex-M7 r0p0 and r0p1: ARM: single stepping Cortex-M7 enters pending exception handler 

:: Morten

 

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

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

Meolsen,

Yea, I found that a little while ago. What I can't find now is:

1) What is the core version that Atmel is producing in their current SAME70 chips? Apparently I have r0p0 or r0p1 on my target board(s), which is an SAME70 Xplained, and a design for our product using a recently purchased SAME70Q21 chip.

2) How to poll the chip itself for the core version number?

3) How to disable all interrupts in Studio 7 so I can try continuing the debug.

 

Thanks

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

1) What is the core version that Atmel is producing in their current SAME70 chips? Apparently I have r0p0 or r0p1 on my target board(s), which is an SAME70 Xplained, and a design for our product using a recently purchased SAME70Q21 chip.

I would look in the DS... 

 

2) How to poll the chip itself for the core version number?

At least the SAM information is encoded in the CHIPID part. Not sure if there's anything similar for Cortex (maybe have a check through the CMSIS headers?).

3) How to disable all interrupts in Studio 7 so I can try continuing the debug

You have to do that in your application.

 

:: Morten

 

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

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

If by "DS" you mean Data Sheet, I have. I've tried searching through the 1800+ page manuals, and I can't find anything...

You have to do that in your application.

Unfortunatly I'm a bit of a novice with this chip. So I'm not 100% up to speed. Give me a clue as to how to turn the ints off. I'm coming from the 8051 world to this chip in one step, so it's a BIG step. I'm not even 100% what do do with the CMSIS suggestion you made. Sorry.. Help?

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

If by "DS" you mean Data Sheet,

Yes

 Give me a clue as to how to turn the ints off.

Have no idea (I'm mainly doing AVR)

:: Morten

 

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

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

No worries, got it. Found a call in FreeRTOS that turns off all interrupts and can single step during this state.

Going to have to try to contact someone at Atmel, Microchip, or a rep to find out about the core revision. Obviously not r0p2.

Thanks for your help.

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

To get core revision:

uint32_t creg;

creg = SCB->CPUID;
printf("CPUID = %x\r\n",(unsigned int) creg);

Output from my board:

CPUID = 410fc271

 

From "ARM Cortex-M7 Processor Technical Reference Manual:

1.7 Product revisions
        This section describes the differences in functionality between product revisions:
              r0p0 First release.
              r0p1 The following changes have been made in this release:
                      • Updated CPUID reset value, 0x410FC271.
                      • Various engineering errata fixes.
             r0p2 The following changes have been made in this release:
                      • Updated CPUID reset value, 0x410FC272.
                      • Various engineering errata fixes.
             r1p0 The following changes have been made in this release:
                      • Updated CPUID reset value, 0x411FC270.
                      • Added CTLPPBLOCK[3:0] to allow locking of registers ITCMCR,
                                  DTCMCR, AHBPCR, VTOR to prevent unwanted updates.
                      • Added ACTLR bit functions to allow low-capability AXI systems to
                                  disable AXI reads to DEV/SO memory and disable exclusive reads/writes
                                  to shared memory not initiated until all outstanding reads/stores on AXI are
                                  complete.
                      • Added MBISTIMPERR[2] output to MBIST interface to provide an error
                                  when attempting to access unimplemented memory.
                      • Improved handling of simultaneous AHBS and software activity relating to
                                  the same TCM.
             r1p1 The following changes have been made in this release:
                      • Updated CPUID reset value, 0x411FC271.
 

 

 

 

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

Doh... Of course in SCB...

:: Morten

 

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

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

I want to thank everyone for their help.

My SAME70 reports 0x410FC271.

Now to find out if Atmel is producing silicon with the newer version core.

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

Any luck with finding if newer SAME70 are >r0p1?

The SAME70Q21 from my Xplained board is also r0p1 and exhibits the same probem.

Thanks,

Daniel

PS: in their "SAM E70/S70/V70/V71 Family Silicon Errata and Data Sheet Clarification" pdf , chapter 3.1 "ARM® Cortex®-M7" they talk about 2 silicon revisions "A" and "B", but both seem to be affected by some Core issues (not sure what). My board has "A" revision and its r0p1. Anybody knows what core is used on the "B"?

Daniel

Last Edited: Sat. Mar 3, 2018 - 08:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

DaPa1 wrote:
Any luck with finding if newer SAME70 are >r0p1?

 

Yes, I just received some SAME70Q21 chips from Microchip that are Rev B. I specifically requested Rev B chips because of the debugging issue. I had to wait about 6 weeks to get them because apparently they are just starting to be produced. But, I can confirm the core is r1p1 and the debugging issue with single step is FIXED!

 

The CPUID now reports as 0x411FC271 (was 0x410FC271 on Rev A chips)

The Device Signature is 0xA1020E01 (was 0xA1020E00)

 

Even though the signature has changed, the chip drops right into an existing Studio 7 project for SAME70 without issue. We were afraid the change in IDs might cause some kind of issue requiring reconfiguration of the project, but didn't.

 

I don't know how long it will take for these to reach the distribution pipeline.

 

I should also add that the Rev B chips have some changes in the GMAC peripheral. Three additional priority queues were added (for a total of six). Software using Ethernet on the Rev A chips may not work on the Rev B chips without modifications to initialization/drivers.

Last Edited: Wed. Apr 11, 2018 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Jeff,

I had a project successfully running on SAMe70Q21 REV A.

Now I want to run my project on REV B. As you decribed Ethernet have some issue to run.

Before I starting to search this Issuse by my own. Do you have any tips how to run GMAC dirvers with REV B chip

Best Felix