using functions in nrf_flash.c with nrf5_SDK_for_Mesh_v1.0.0

RE: using functions in nrf_flash.c with nrf5_SDK_for_Mesh_v1.0.0

leonwj — Tue, 27 Feb 2018 15:41:48 GMT

Yes, there are 2 vector tables in play... On ARM Cortex-Mx there is a system vector table @0x00000000 and then your application will store a vector table of all your implemented handlers at its base address... (Although it's related to a different issue, RK explains it fairly well on this post from a few years back.)

Looking at the included table below, you should find that the 0x08c8 address is reached via the 0x08c5 entry in the HardFault index (see offset 0x0C).

As I mentioned above, I would recommend that you implement your own handler to determine the exact hardfault reason and the exact line/location which caused it.

Regards,

RE: using functions in nrf_flash.c with nrf5_SDK_for_Mesh_v1.0.0

aleccontrol — Tue, 27 Feb 2018 14:46:52 GMT

Looks like you may be right that it is likely a Hard Fault but happening somewhere in the softdevice because when I wrote other codes that may have crashed the processor the debugger stop at the same place 0x8c8. Now I have to find out how to determine the source of the hard faults....

Questions: Is there another, different HardFault_handler in the softdevice that is different from the HardFault_Handler in the example application code provided by the mesh stack?

RE: using functions in nrf_flash.c with nrf5_SDK_for_Mesh_v1.0.0

aleccontrol — Tue, 27 Feb 2018 07:49:14 GMT

Thank you for the suggestion. My program only starts from address 0x23000 and my map listing does not show the content of functions before the starting address 0x23000. Also the HardFault_Handler function found in the nrf_mesh_sdk is located at 0x235cc, as shown below.

I believe the flash memory before 0x23000 is likely to be occupied by the softdevice. Does the linker map provide any clue about functions in the softdevice that is not part of my program?

RE: using functions in nrf_flash.c with nrf5_SDK_for_Mesh_v1.0.0

leonwj — Mon, 26 Feb 2018 20:47:38 GMT

Based upon the screenshot you provided, it appears to be in the HardFault Handler (which you can confirm on your end by either looking at the vector table pointers and/or the .map file).

Once you confirm the above, it's then a simple matter of tracing back to determine the exact hardfault reason and the exact line/location which caused it.

Regards,