No Debug information

Hi all.

I have an old problem in a project and it keeps popping up now and then. I think the problem is related to a UART driver I wrote.
On the UART I have GPS and modems. Now and then I have errors on these devices and sporadically the system goes into the watchdog.

If I try to debug when I have errors on the GPS I often get the attached error.

How can I proceed?

Best Regards


Parents Reply Children
  • I reviewed your whole post.  The first error does look like a bad pointer or something else corrupting the stack and jumping to that bad address.  When you say "no debug information" I'm not sure what that means.  Is the "call stack" garbled in the debugger?  Somehow the code is jumping to that address and there should be a call stack.  Have you looked at the hardware state and some of the registers to see where it came from - see the link below on debugging hard faults.   You can manually try to go through the stack chain and look at the return addresses to see where to code was running.

    A trace may help to see how you got there - a regular Segger or IAR does not have great trace capability, but you may be able to get function call traces to help see what code was executing.  A better trace IAR IJet trace or a SEgger J-Trace might be able to capture the execution path prior to the fault.

    You might also consider adding ITM macro calls calls in the code and using the debugger to visualize the execution path when it's working and then when it fails.  You include arm_itm.h nad then put in ITM_EVENT8(itm#,value) in the code and visualize them in the event log.

    I'll take some time but you'll find it eventually.  

    Good luck

  • Hi.
    Thanks for the info. The thing is, I am presented with a different scenario every time.
    I put a breakpoint inside the R_ICU-> NMISR_b.SPEST flag check and there appears to be a stack overflow. The threads stacks are ok.

    Overflow fires with a memcpy. Now I am investigating why.

    I'll update you if I find anything.


  • Your crash reminds me of something I had a while back - the jump to nowhere and the memcpy causing it.

    Now I have to remember what is was.  If it wasn't stacks, it could have been mem pools - running out of packets for netx or usbx.  You using the command to keep track of what's left in your pools?

  • I didn't understand what you mean by the sentence: "You using the command to keep track of what's left in your pools?".  If you refer to the information I have from RTOS Resorce I have not seen anything strange.

    I put some checks and commented some threads (it goes by exclusion).


  • Hi Paolo-

    Do you still have your issue? What MCU and version of SSP are you using? Does this post apply to your application? 

  • Sorry for the delay and confusion.  We had shell commands to see what was remaining and the netx and usbx mem packet pools as I remember.  We also had issues with memory fragmentation and malloc/new not returning blocks large enough when memory was unavailable.  

    Using a TraceX tool might be best if you're still having this issue.

  • Hi WarenM and Iarry.

    I'm still investigating, but writing my version of memcpy in C ++ and porting some code from C to C ++ things seem to get better. In my project I have avoided malloc / new functions.

    I still have some stability bugs, but I'm investigating.

    Best Regards


  • Hi Paolo-

    Thanx for keeping us informed.

  • Hi WarrenM.

    During this time I have been involved in other projects, but I hope to return soon to investigate the problems.

    Have a nice days.