Home/Support/Support Forum/How to debug random invalid memory access in NETOS?
Welcome to Digi Forum, where you can ask questions and receive answers from other members of the community.

How to debug random invalid memory access in NETOS?

0 votes
Hi,


After a while running in production environment some systems are calling the exception handler customizeErrorHandler() in file src\customize\errhndlr.c. I could not reproduce any scenario, but it happened once when I was investigating other issue with debugger attached to the module and could examine the stack of the running thread processing the exception NA_EXCEPTION_DATA_ABORT. What do you recommend to track down the root cause of this exception?

System information:
Connect ME 7520 running NET+OS 7.4
DigiESP for NET+OS 7.5

Regards,

Alberto Reis
asked Jan 25 in NET+OS by areis New to the Community (4 points)

Please log in or register to answer this question.

1 Answer

0 votes
get a moduleProbably execution hit one of the exception handlers. It is easier to use JTAG then LEDs to debug when running out of the debugger.
Before you try to debug this as described below, please run the unmodified example on unmodified standard BSP, as described above. If you will be able to single out what change cases crash it will greatly simplify further debugging.
You can check it by putting breakpoints at customizeErrorHandler() and on entry of all exception handlers in init.s (init.arm) file (Undefined_Handler, SWI_Handler Prefetch_Handler, Abort_Handler, Address_Error_Handler, crash). Once you will get an exception , you will hit one of those breakpoints and you will know what exception did you get. Once this happens, look at the link register (LR) - go to the instruction that is on address pointed by the LR - you may have to switch to mixed mode where both C and assembly language instructions are displayed. Once you there, put a breakpoint on the previous instruction – this is the line that caused look and try to figure what this instruction is doing. If it is not HW exception, you can look at the call stack when you hit your breakpoint at customizeExceptionHandler() and see how you got there.
You can put breakpoint in inti.arm – use DIGI ESP debugger’s console (it’s a regular gdb console actually and it accepts regular gdb commands)
Use commands:
b Undefined_Handler
b SWI_Handler
b Prefetch_Handler
b Abort_Handler
b Address_Error_Handler
b crash

etc to set breakpoints
with JTAG and reproduce a problem there:
answered Jan 29 by LeonidM Veteran of the Digi Community (2,821 points)
...