Hi,
My application has hard faults sometimes, and I'm trying to figure out the reason.
When it occurs - I have a hard fault log, but p_stack->pc is 0. I can't understand what is the problematic code line.
Do I have another ways to catch the issue?
Thanks!
if the PC value in the stack frame for the hardfault reads 0, then it is very likely that you had a memory corruption that contributed to the hardfault. You need to debug such scenarios by stepping through the code until you understand the context of the hardfault (the hard debugging way)
The problem that it occurs randomly, and it doesn't happen due to specific code lines (already tried the hard way). Can it be related to memory space? Maybe increasing memory can solve the issue?
Thanks!
In addition - I have a log of the following lines:
HARD FAULT at 0x00000000
R0: 0x00000010 R1: 0x00000000 R2: 0x20007908 R3: 0x00000000
R12: 0x20011F34 LR: 0x0003262F PSR: 0x00000000
Cause: The processor has attempted to execute an instruction that makes illegal use of the EPSR.
Can it help me?
Thanks!
The hardfault stack frame seems incorrect, that means that wrong stack frame might have been popped into the registers. Which means that some of the stack buffers might have overflowed causing the the next stack frame to get corrupted.
Trying disabling logs to see if logs buffers are overflowing (disabling logs should fix the issue if logs buffers are too small for your application). If that does not help, then try to increase the buffer size of modules (in sdk_config.h) one by one to figure out which module's buffer is overflowing. Unfortunately, this could be a tedious debugging session.
The hardfault stack frame seems incorrect, that means that wrong stack frame might have been popped into the registers. Which means that some of the stack buffers might have overflowed causing the the next stack frame to get corrupted.
Trying disabling logs to see if logs buffers are overflowing (disabling logs should fix the issue if logs buffers are too small for your application). If that does not help, then try to increase the buffer size of modules (in sdk_config.h) one by one to figure out which module's buffer is overflowing. Unfortunately, this could be a tedious debugging session.
Hi,
I can't understand which buffers can be changes in sdk_config.h.
Can you please explain?
Thanks!
In addition - the hard fault occurs in a specific function.
When testing performance of this function - I've noticed that CPU usage of one of the services if very high (about 800%).
Can it be related to the hard fault?
Thanks!
Roei said:In addition - the hard fault occurs in a specific function
Is this a function from a Nordic solution? Which function is it?
Roei said:When testing performance of this function - I've noticed that CPU usage of one of the services if very high (about 800%).
the percentage of CPU usage should not be the reason for the hardfault. It might be the memory usage by that function. But if you know the function that causes this hardfault, then you can step in and debug to see which line exactly causes this. If this function is from the the Nordic solution (SDK) then i might be able to help you debug it if you help me reproduce it at my desk.
It's not a function from the SDK of Nordic solution - it's a new function which make a lot of job - writing and erasing a lot of pages from an external flash (using SPI protocol).
Already tried to debug and didn't find any specific line. It is also occurs not very often.
Roei said:It's not a function from the SDK of Nordic solution - it's a new function which make a lot of job - writing and erasing a lot of pages from an external flash (using SPI protocol).
In that case, this memory corruption is hard to track from our side as these seems to be introduced with your changes. And with the minimal information given and no way to reproduce on our end, it is very hard for me to narrow down the problem for you.
