This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

using functions in nrf_flash.c with nrf5_SDK_for_Mesh_v1.0.0

I am developing a Bluetooth Mesh program to run on the nRF52832 development board. I started by modifying the "nrf5_SDK_for_Mesh_v1.0.0_src\examples\light_switch\server" program which I have already tested to work the the board running the "nrf5_SDK_for_Mesh_v1.0.0_src\examples\light_switch\client" program.

I initially commented out the statement:   

//  ERROR_CHECK(nrf_mesh_node_config(&config_params));

so that I can step through my own codes without the mesh stack throwing exception (probably due to time out). I have added codes that will call the nrf_flash_erase() and nrf_flash_write() functions found in the nrf_flash.c file. The program works well and I can erase and program any flash memory location on the nRF52 SoC.

However, once I enable the mesh stack by allowing the statement   " ERROR_CHECK(nrf_mesh_node_config(&config_params));" to run, then calling the nrf_flash_erase() will result in the program stopping at the following location 000008C8 (is this the location in the softdevice?)

I then step through the program by pressing F10 when it stopped at the above location, after stepping pass the line at 08CE the program with restart from beginning

When I step through the nrf_flash_erase() function I noticed that once the following statement is run the program will immediately stop at the 08C8 location as shown in the above screen capture.

NRF_NVMC->CONFIG = (NVMC_CONFIG_WEN_Een << NVMC_CONFIG_WEN_Pos);

What is the reason for this? It doesn't appear to be a timing issue because the flash was not yet being erased. Just accessing the CONFIG register in the NRF_NVMC is sufficient to cause the program to stop.

How can I get around this issue as I need to be able to access about 32K bytes of flash space contiguously and the "Flash Manager" that comes with the mesh stack doesn't seem to be  suitable for my purpose.

Thank  you very much for any help.

Parents
  • 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,

  • 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?

  • 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?

  • 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,

Reply
  • 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,

Children
No Data
Related