z_arm_usage_fault in CC_PalPowerSaveModeSelect on my custom board

[sprhawk]

Here is my backtrace

Here is my schematic design:

8585.nrf52840-lte-tracker-nRF52840.pdf

I measured VDD_nRF is 1.8V

The code was running on nRF52840 DK

here is my build .conf

build_config.txt

[Charlie]

Hi Hongbo,

Thanks for checking with us about this issue.

Do you mean this issue only appear on your custom board, same codes running on nRF52840DK is OK?

Are your codes are based on a specific NCS samples in Samples — nRF Connect SDK 2.6.1 documentation (nordicsemi.com)?

I see a similar report on Kernel usage fault when using semaphore with multi-threading · Issue #41963 · zephyrproject-rtos/zephyr (github.com), could you try the solution mentioned in https://github.com/zephyrproject-rtos/zephyr/issues/41963#issuecomment-1023920219 ?

Best regards,

Charlie

[sprhawk]

Are the `CC_` functions inside binary lib provided by nordic which I cannot trace into ?

I'll try it later.

Will non-function 32Mhz crystal cause similar fatal errors ?

[sprhawk]

My main stack had been increased to 8K to support my application before, and have disabled all other application code.

Now it showed this:

I checked the definition, it is "K_ERR_ARM_BUS_IMPRECISE_DATA_BUS"

[sprhawk]

Found the reason:

I used the debug output from a nRF52832 DK, for some reason, it debugged onboard nrf52832 instead external nRF52840.

I read the FICR INFO registers to find it out.

[sprhawk]

Then a question is: doesn't JLink verify Chip ID before entering debug status ?