Hi,
I am using nrf52840 and nrf SDK 16.0. Our board is getting reset sometimes and the reset reason is CPU lock-up detected.
why and when does board reset from CPU lock-up? How do we fix this?
Thank you,
shreya
Hi,
I am using nrf52840 and nrf SDK 16.0. Our board is getting reset sometimes and the reset reason is CPU lock-up detected.
why and when does board reset from CPU lock-up? How do we fix this?
Thank you,
shreya
Hi,
This is often a result of a hardfault inside a hardfault,
Have you checked your log output and see if it indicates any hardfault?
regards
Jared
Hi Jared,
I have caused hard fault condition in our device by performing (1/0) and we are getting reset reason as 4, i.e. soft reset.
Actually, we don't have the debug logs. we have the deployed our device. and it is resetting sometimes. The reset reason is 8 i.e. reset due to CPU lockup.
can you please help in debugging which code caused this reset?!
Thank you,
Shreya
Ok, my understanding is that the issue that you see with the deployed devices is that they reset with the CPU lockup bit being set in RESETREAS, which can indicate a hardfault. Thus, I think we need to focus on understanding the cause of this hardfault.
If CPU lock reset occurs following HardFault_Handler() gets executed ? Further this function calls the NVIC_SystemReset() which indicate the softreset. In this case how will the controller manages to indicate the CPU lock reset reason in RESETREAS instead of softreset?.
Ok sure we are creating the deployment scenario and will share the logs. Since we cann't completely reproduce the deployment enviroment, we are planning to collect the hardfault information & store in flash. After reset, we read from flash & transmit in BLE packet.
From Hard fault can we collect the file name and line number which cause this issue?. If not what else we can collect? Can you let-us know what all information we can collect ?
Thank you,
Shreya
Hi Jared,
can you please reply ASAP!
thank you
Shreya
Hi,
As I've stated in my initial reply, it's difficult to pinpoint the root reason for a CPU lockup. A such state indicates that the CPU for some reason is in a such erroneous state, so that the only way to recover is to do a reset. The reason for being in this state can be that the device hardfaults and then hardfaults again.
Shreya J B said:From Hard fault can we collect the file name and line number which cause this issue?. If not what else we can collect? Can you let-us know what all information we can collect ?
I think this is complicating it a bit. Couldn't you just connect the device to a serial terminal and let it run, and then read out the log output when it asserts?
Hopefully you could recreate the conditions inside a lab?
regards
Jared
Hi,
Thank you for the information. we are trying to recreate this condition. the test is under process. once we receive will get back to you.
Thank you,
Shreya
Good,
Please share the logs once you have them,
In the meantime here is some questions you could answer:
regards
Jared
Good,
Please share the logs once you have them,
In the meantime here is some questions you could answer:
regards
Jared
Have you been able to reproduce the issue on a development kit?
We are using custom hardware. It will not be possible to recreate with it.
Can you describe what your application does? Does it use Bluetooth, is it a beacon or in a connection etc?
It works in BLE connected mode
Do you have a bootloader on the device?
Yes
Does the device do any flash operations?
Yes
How long was the device operating in field before you saw the issue? 7-days? Or has the device been in field for longer.
More than 5 months
Hi.
Can you share the schematics?
I can make the case private first if you prefer it,
regards
Jared