Xmega256A3U "reset"?

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

Any ideas what could cause the chip to do a "reset" leaving all RST.STATUS bits zero?

Could there be something in the ASF library that could cause a jump to reset vector without actually doing a reset?

 

In the beginning of main I have a breakpoint after which I write 0x3F to the RST.STATUS (both before an eternal loop) .

When I start debugging the breakpoint "fires" and the PDIRF-bit is set (as expected). On 'continue', the bits are reset and after a while

the breakpoint before the eternal loop fires again, but now the RST.STATUS is all zeroes.

 

The stack seems to be OK - checked by putting a breakpoint at __init (0x000006cc) on one such run.

 

This topic has a solution.

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

Last Edited: Fri. Nov 23, 2018 - 06:06 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A reset where the bits are 0 means that execution simply returned to location 0. If using avr-gcc the most likely cause is often an unhooked ISR. Read about "catch-all interrupt" in the manual at:

 

https://www.nongnu.org/avr-libc/...

 

So you are likely enabling an interrupt source for which you have not provided the ISR(). Does your build have any warning about "mis-spelled interrupt handler" ?

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

Loads of thanks!

 

I'm bebugging someone else's code.

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

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

Hmm, it was not that, although got it once to a breakpoint within the BADISR-handler.

There were also jumps to reset vector that didn't go through a bad ISR.

I suspect that some way the stack is messed up in an ISR, and a subroutine returns straight to tha reset vector without executing the interrupt return...

 

Any idea if the avr-gcc optimizer uses Pascal calling convention? (Subroutine cleans the stack.)

 

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

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

turboscrew wrote:
Any idea if the avr-gcc optimizer uses Pascal calling convention? (Subroutine cleans the stack.)
The AVR GCC ABI is documented here:

 

https://gcc.gnu.org/wiki/avr-gcc

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

It starts to look like NULL-pointer problem. Something somewhere might be writing in the I/O space.

 

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

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

Does this explain anything?

 

09:56:14: [ERROR] Unexpected response (0x70) received from the debugger. Debugger command Memory read failed., ModuleName: TCF (TCF command: StackTrace:getChildren failed.)
09:56:14: [ERROR] Unexpected response (0x70) received from the debugger. Debugger command Memory read failed., ModuleName: TCF (TCF command: Registers:getm failed.)

 

 

Now breakpoint at __init

All device registers are zero except SREG and SP (and PC). (SP in legal region, 68 bytes in stack)

 

Also:

 

No disassembly available.

 

Unable to evaluate the expression.

Also all watched variables are zero.

Giving reset from debugger doesn't seem to clear the state.

 

Is this some special HW state?

 

 

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

Last Edited: Fri. Nov 23, 2018 - 08:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

turboscrew wrote:
No disassembly available.
usually means the code has not been built with -g so there's no info in the ELF to map the binary to source file lines

turboscrew wrote:
Unable to evaluate the expression.
That's just standard for optimized code - it means "I can't "see" the value in at least one of the things in this expression"

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

Those are messages in disassembly window and memory window.

And after break.

At the start (break at main) they were available.

 

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

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

After some more debugging, it starts to look like it has to be HW problem.

I think some simultaneous I/Os might cause a notch in the supply voltage(s).

 

Thanks for the help. If it didn't solve the problem, at least I got wiser. ;-)

 

I just don't know what to mark as "solution".

Maybe the most enlightening posting...

Debugging is for sissies and delivery for surgeons. Real men do demonstration.

Last Edited: Fri. Nov 23, 2018 - 06:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

turboscrew wrote:
I think some simultaneous I/Os might cause a notch in the supply voltage(s).
likewise by a certain instruction sequence.

XMega SRAM slow turnaround? - Solved (Glitchy Power Supply).

...

https://www.avrfreaks.net/forum/xmega-sram-slow-turnaround-solved-glitchy-power-supply#comment-1028546

...

XMEGA schematic checklists show an inductor between the XMEGA and its power that should reduce the likelihood of making the power supply unstable.

Power supply stability (error amplifier gain margin) can be evaluated by a low frequency network analyzer or a low frequency spectrum analyzer with a tracking generator.

 

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