• State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 90 subscribers
  • Views 2497 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 284252
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Using wait_for_flash_ready() causes firmware to restart after exception

crl

Hi,

this is kind of continuation of my previous ticket. After solving it the last time I thought that I don't need wait_for_flash_ready() function as it caused some problems and the code was working good enough without it. Right now I face the problem once again, but this time I know nrf_fstorage_write is not reliable in terms of saving just in time before reboot (I have to reboot and reload data to RAM after writing to flash, this was a way the previous developer solved an issue). I have to use wait_for_flash_ready() as it is the only way to make sure flash is saved properly which is what I have problem with. In my opinion just adding a wait for the flag is enough to ensure data is saved properly and then go with what the code does right now.

I am using copied parts of code from fstorage example. When the code calls wait_for_flash_ready() it reaches SVCALL(SD_APP_EVT_WAIT, uint32_t, sd_app_evt_wait(void)); in nrf_soc.h (sdk/components/softdevice/s132/headers) and there an exception occurs.

The main problem is that I receive some data (200 bytes) via Bluetooth, I have to write it to flash, reboot, read flash and throw the data into RAM, use it for calculations. Problem is that I am not sure the data is saved properly plus 3 of 200 bytes are always changed in comparison to what I received. For example I should receive 0x21 as the last byte but the code says it got 0xE4, after reading the flash it once again is 0x21. In another place I receive 0xB7 0x03 but after sending it to function as a pointer I know that it changed to 0x05 0x04. This is odd, so I'm trying to cover all deficiencies in code.

Extending or even removing scheduled reboot does not work. I can wait for a few minutes (without wait_for_flash_ready in code) but it looks like nothing changes.
In sdk_config I have FDS_BACKEND configured to use SD (FDS_BACKEND 2).

Small recap: I'm using SDK 17.0.2, my IDE is VSCodium (VSCode) under Linux with GCC as a compiler for nRF52832.

Any idea what goes wrong?

  • 0

    Hi,


    I am using copied parts of code from fstorage example. When the code calls wait_for_flash_ready() it reaches SVCALL(SD_APP_EVT_WAIT, uint32_t, sd_app_evt_wait(void)); in nrf_soc.h (sdk/components/softdevice/s132/headers) and there an exception occurs.

    What kind of error is thrown? Could you share a screenshot from debug view highlighting the error?

    regards

    Jared 

  • 0 in reply to Jared

    There is no error during J-Link - terminal debugging but using Cortex Debug plugin in VSCode throws "Exception has occured" as a baloon and not much else. In terminal I can see that even if I let the program run without breakpoints it stops at specific points where flash is erased or written to.

  • 0 in reply to crl

    About the incorrectly written bytes I just made a simple table which shows (I hope clearly) what happens. Be advised that there are leading zeroes (mostly) that will fill up the structure up to 200 bytes, the structures you see are ending bytes.
    I have not found any signs of in-code modifications of this structure other than flash write/read.

  • 0 in reply to crl

    Hi,

    Could you share your code?

    In sdk_config I have FDS_BACKEND configured to use SD (FDS_BACKEND 2).

    This definition is relevant for the flash data storage(fds) module, not the flash storage(fstorage) module which is a lower-level module. 

    regards

    Jared

  • 0 in reply to Jared

    Hi,

    Unfortunately I cannot share my code explicitly, rewriting it to paste it here might not be useful as it will look like the one used in an example.

    As my collegue found, the sdk_config.h used in this project is older than used sdk (copyright 2019 vs 2020). Might that or inproperly configured config file be the case?
    I will include the newer one first, then include project-oriented config and check if it will help.

    [EDIT]

    I found out that sdk_config.h is oddly included, I will redo it. For previous testing I just added two includes into main but nothing changed, nrf_wait_for_flash_ready() still causes a restart.

    I found out why previously I just used __WFE(). Function power_manage from fstorage example has a macro that depends on SD (if it is present) but the only difference is that with SD present it returns NRF_SUCCESS. If I put __WFE() into my wait_for_flash_ready function it will crash. __WFE is a macro defined in CMSIS, so it should be properly working. I will investigate how the CMSIS is used as that will probably be the source of all this hassle.
    [I was wrong here. VSCode sent me to wrong file (nrf_soc_nosd). I should've looked at softdevice/s132/headers/nrf_soc.h and here sd_app_evt_wait is called by SVCALL which causes the fault. Anyway, __WFE used directly causes fault too, but it should not be used with SD.]

Related
Terms of service