Exception in AVR

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

Hello experts

 

Basically i have a AVR32UC3C0512 chipset we encountered multiple times exceptions when i look in the file exception.S most of it is in assembly with multiple exception handlers executing

rjmp $ which is nothing but an infinite while loop

 

so i want to track down each of the exception and trace what was the reason for exception by printing some useful information on the log file.

can someone please help with assembly code which can do that

 

Regards

 

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

Not sure how similar to ARM the UC3 is but the classic reason you keep hitting the exceptions in ARM is if you try operating instructions on data with the wrong alignment (like a 32 bit, 4 byte load from a location that is not 4 byte aligned etc). Could it be something similar?

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

Nick123 wrote:
i want to track down each of the exception and trace what was the reason for exception by printing some useful information on the log file.

If you've hit an Exception, it means your system is (probably) in a bad state - so trying to do stuff like printing, or using a filesystem may well not be reliable.

 

A more common approach would be to set a breakpoint in each handler, and then examine the call stack in the debugger.

 

Or write some data to a RAM area that will not be overwritten on startup, and examine that when the system restarts.

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

thanks Raving

 

i agree with your solution but i think it is not very efficient in our case because of the device is a bit like a robot machine when we execute out  software the robots runs all over a fixed area hence Breakpoint and single step

are not the solution for us

what i am trying to achieve is

rather my approach would be remove the rjmp $ in each exception and replace it with something assembly code which can either output some value on the GPIO pin every seconds or every 100 millisecond & reads the call stack 

which will indicate one of the exception & to find the reason for the exception we some how need to read the call stack and print it on the file or on the terminal. since the exception.S is in assembly we must do the coding in assembly language

--------------------------------------------------------

_handle_Unrecoverable_Exception

_handle_TLB_Multiple_Hit

_handle_Bus_Error_Data_Fetch

_handle_Bus_Error_Instruction_Fetch

_handle_NMI

_handle_Instruction_Address

_handle_ITLB_Protection

_handle_Breakpoint

_handle_Illegal_Opcode

_handle_Unimplemented_Instruction

_handle_Privilege_Violation

_handle_Floating_Point

_handle_Coprocessor_Absent

_handle_Data_Address_Read

_handle_Data_Address_Write

_handle_DTLB_Protection_Read

_handle_DTLB_Protection_Write

_handle_DTLB_Modified

_handle_ITLB_Miss

_handle_DTLB_Miss_Read

_handle_DTLB_Miss_Write

_handle_Supervisor_Call

---------------------------------------------

 

Regards

 

 

 

 

 

 

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

Nick123 wrote:
i agree with your solution (sic) but i think it is not very efficient in our case

Errr ... I gave two options

 

since the exception.S is in assembly we must do the coding in assembly language

Although it may well be wise for other reasons to code such things in assembler, that statement is a non-sequitur.

 

 

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

awneil wrote:

A more common approach would be to set a breakpoint in each handler, and then examine the call stack in the debugger.

No need in this case.  Once you have a system that's "in the weeds" just connect the jtag debugger and "break-in" on the execution.  Since all the exception handlers are simple infinite loops, the debugger will show which one it is once you "break-in".  From there you can examine the stack, etc. to gather more info as to the cause.

Letting the smoke out since 1978

 

 

 

 

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

Good point - assuming that your debugger allows you to "break-in" on the execution - without first doing a reset.

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

On the old IBM 1130 I learned on way back when, when it encountered an error it would halt, by looking at the address lights one could "see" what the error was that caused the halt.

You could do something similar with some leds, write a uniq light pattern at each vector for each error to the LEDs......

 

Jim