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?
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…
This sounds like it might be related to stack overflow. Have you checked your stacks to see how much room you have in them? Can you look at the call trace to see what the program flow was prior to the exception?
Any additional information you can provide would help.
Hi Warren.I also think it's a stack overflow. The problem is that it is a large project and when it crashes I can't trace it because debug don't work.
I'm trying to convert many parts with pointers to C ++ (avoiding pointers and using std :: array etc using exceptions in debug).
The problem is that I use a lot of C arrays and pointers, it will be a long job.
Sometimes I use Ozone debugger from Segger to run the elf file. I can turn on trace. If the program crashes, I get some trace information and be able to find out which module causes it.
Hi CS Yep.
Many thanks for the information! I didn't know that software. I'll try.
The standard debug technique applies. Put in a hard fault exception handler with a BKPT instruction or a while 1. When it hits the problem, halt and check that call stack. Then also look at all the task stack sizes.
Hi larry.That's what I've been doing for months, I think I've found the problem and then after a while it comes back :(But I'm not giving up :)Have a nice day
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.
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).
Do you still have your issue? What MCU and version of SSP are you using? Does this post apply to your application? https://renesasrulz.com/synergy/f/synergy---forum/15841/memcpy-fails-on-s5d9
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.
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.
Thanx for keeping us informed.
During this time I have been involved in other projects, but I hope to return soon to investigate the problems.
Have a nice days.