WFE() and WFI() give JLINK Trouble

[mookiedog]

I have a home-brew co-routine task management system that uses a WFE() [or WFI()] to sleep in between events that might cause tasks to run. I have been using this software for a couple years now on a SAM3S with no problems. It is a simple mainloop of the form:

Code: Select all

while (1)
{
  _WFE();
  processAllReadyTasks();
}

After upgrading to Studio 7 and the latest firmware for my JLink debugger, I now get very strange error messages within a few seconds of running my program in debug mode. For example, one message says "J-Link V4.98e Internal Error Could not find breakpoint in internal list". Other times, the debugger will stop at a line of code as though I had a breakpoint, but there is no breakpoint at that location.

The strange part is that the debugger crash seems connected to the presence of the _WFE().

#1. If I remove the _WFE(), the system works perfectly as expected, even with the debugger connected.

2. If I flash the version of the code that contains _WFE(), with a debugger connected the program hits phantom breakpoints, or gives me spurious internal errors as described above. But when disconnect the debugger physically from my board (without changing the program or reflashing), the program also runs just fine.

Has anyone else had weird behavior with J-Link V4.98e internal errors?

[mookiedog]

I brought this issue up with the people at Segger, who make my JTAG debugger. They said that they talked to Atmel about it, and that Atmel says that the ATSAM3S processor has a problem with WFE/WFI and debug mode. Specifically, I was told that if the processor is halted at a _WFE() or _WFI() for "too long", the chip will lose its ability to talk to the JTAG debugger. Apparently, some parts of the ASIC that get powered down during a WFI/WFE are parts of the chip that are required to support external debug mode operation.

The workarounds Segger suggested were to A) not use the _WFE()/_WFI() call and live with increased power consumption, or B) to set up some background timer interrupt that would interrupt the CPU at 1 KHz. The 1KHz interrupt apparently doesn't have to do anything except make the CPU wake up and do something before going back to sleep. While the CPU is running due to the interrupt instructions, an external debugger will be able to get the CPU's attention and then do its thing.

For what it is worth, this problem is not listed in the ATSAM3S errata.
In my case, this is a bit annoying since I just spend a bunch of time & effort to make my task system "tickless", and the workaround is to make the system tickfull again.