NRF52840 app - random hard fault

RE: NRF52840 app - random hard fault

Roei — Sat, 01 May 2021 18:08:05 GMT

Hi,

Thanks for your help!

The hard fault occurs in a function which has a lot of external flash write and erase actions (via SPI interface). Hence - I think it may be the reason.

Do you have any ideas?

Thanks!

RE: NRF52840 app - random hard fault

hmolesworth — Fri, 30 Apr 2021 22:27:08 GMT

Maybe the issue is with an interrupt allocating too much stack space by using (say) a print buffer inside the interrupt, so the interrupt generates the hard fault in "random" foreground code locations since the buffer is allocated on the stack in the interrupt before the interrupt code executes, which generates another hard fault interrupt. This probably only happens under worst-case stack usage scenarios, so rare. This is what Susheel is driving at, I think.

"Pointer to the stack bottom. This pointer might be NULL if the HardFault was called when the main stack was the active stack and a stack overrun is detected. In such a situation, the stack pointer is reinitialized to the default position, and the stack content is lost."

In such a case, examine all interrupt (event) handlers and remove any buffers and instead set a flag and process in (say) the main loop.

A second (classic) scenario is that a function allocates a local buffer on the stack using a variable parameter as the size of the stack; IAR would warn against that but SES does not. If the is an error in that parameter then the stack blows up. No good checking the parameters since the stack blows up before the parameters can be checked. Some of the TWI example code has this "feature" (or used to).

RE: NRF52840 app - random hard fault

Roei — Fri, 30 Apr 2021 21:01:54 GMT

Hi,

Can you please tell me where can I increase beffurs size in sdk_config.h?

Thanks!

RE: NRF52840 app - random hard fault

Susheel Nuguru — Wed, 07 Apr 2021 11:49:57 GMT

[quote user="Roei"]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).[/quote]

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.

RE: NRF52840 app - random hard fault

Roei — Wed, 07 Apr 2021 11:24:45 GMT

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.

RE: NRF52840 app - random hard fault

Susheel Nuguru — Wed, 07 Apr 2021 11:21:21 GMT

[quote user="Roei"]In addition - the hard fault occurs in a specific function[/quote]

Is this a function from a Nordic solution? Which function is it?

[quote user="Roei"]When testing performance of this function - I've noticed that CPU usage of one of the services if very high (about 800%).[/quote]

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.

RE: NRF52840 app - random hard fault

Roei — Wed, 07 Apr 2021 10:00:55 GMT

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!

RE: NRF52840 app - random hard fault

Roei — Wed, 07 Apr 2021 07:59:32 GMT

Hi,

I can't understand which buffers can be changes in sdk_config.h.

Can you please explain?

Thanks!

RE: NRF52840 app - random hard fault

Susheel Nuguru — Sun, 04 Apr 2021 15:56:18 GMT

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.

RE: NRF52840 app - random hard fault

Roei — Tue, 30 Mar 2021 19:07:57 GMT

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!

RE: NRF52840 app - random hard fault

Roei — Tue, 30 Mar 2021 08:18:44 GMT

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!

RE: NRF52840 app - random hard fault

Susheel Nuguru — Tue, 30 Mar 2021 08:13:58 GMT

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)