Flash read error 16 [NRF_ERROR_INVALID_ADDR] when code executing outside of debugger

[NickH]

When I run my code using Segger debugger, all is well and I can read and write from flash with issues.  However, when I run the same code independently I sometimes get:

ASSERT ERROR 16 [NRF_ERROR_INVALID_ADDR]

when calling:

#define FLASH_START_ADDRESS 0x7e000

#define FLASH_END_ADDRESS   0x7ffff

…

ret = nrf_fstorage_read(&fstorage, FLASH_START_ADDRESS, buf, size);

APP_ERROR_CHECK(ret);

at this point buf is 1940 bytes.

The application RAM start is 0x200039d8 as determined by nrf_sdh_ble_enable().

My set-up is:

Module: nrf52840

Hardware: nrf52840 DVK and custom board

Soft Device: s140_nrf52_7.2.0_softdevice

SDK: nRF5_SDK_17.0.2_d674dde

Memory Segments:

FLASH RX 0x0 0x100000;RAM1 RWX 0x20000000 0x40000

Section Placement Macros:

FLASH_PH_START=0x0

FLASH_PH_SIZE=0x100000

RAM_PH_START=0x20000000

RAM_PH_SIZE=0x40000

FLASH_START=0x27000

FLASH_SIZE=0x2a222

RAM_START=0x200039d8

RAM_SIZE=0x3dda0

Stack and Heap both set to:

32768 bytes

I did notice that when code downloaded via Segger and then viewed via nRF Connect programmer, there is a memory chunk starting at 0x7000 and ending 0x7e676.  [I don’t know why this is not either the size of my file ie 1940 bytes or the 0x7ffff specified as flash end address.]

I also don’t get this memory chunk when the code is run after being downloaded via nrfjprog or nRF Connect programmer but either way, I still get the invalid address error.

I’m clearly misunderstanding something here and would be grateful for some pointers….

Nick

[Jørgen Holmefjord]

Hi,

According to the API documentation, nrf_fstorage_read() return NRF_ERROR_INVALID_ADDR in two cases; "If the address addr is outside the flash memory boundaries specified in p_fs, or if it is unaligned."

Are you passing the same defines to NRF_FSTORAGE_DEF?

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
    /* Set a handler for fstorage events. */
    .evt_handler = fstorage_evt_handler,

    /* These below are the boundaries of the flash space assigned to this instance of fstorage.
     * You must set these manually, even at runtime, before nrf_fstorage_init() is called.
     * The function nrf5_flash_end_addr_get() can be used to retrieve the last address on the
     * last page of flash available to write data. */
    .start_addr = FLASH_START_ADDRESS,
    .end_addr   = FLASH_END_ADDRESS,
};

You can try to run 'nrfjprog --eraseall' to erase all flash content, before flashing the application again. That should remove the data in 0x7000 to 0x7e676 if this is written by an old application, etc.

I tried to reproduce you error, but I was not able to. Maybe you can upload the full project?

Best regards,
Jørgen

[Jørgen Holmefjord]

How does your NRF_FSTORAGE_DEF() look?

You can upload the project here (Insert -> Image/Video/File), or at any file sharing service and post a link. If you do not want to share in public, I can convert this case to private.

[NickH]

#define FLASH_START_ADDRESS 0x7e000
#define FLASH_END_ADDRESS   0x7ffff

NRF_FSTORAGE_DEF(nrf_fstorage_t fstorage) =
{
    /* Set a handler for fstorage events. */
    .evt_handler = fstorage_evt_handler,
    .start_addr = FLASH_START_ADDRESS,
    .end_addr   = FLASH_END_ADDRESS,
  
};

[Jørgen Holmefjord]

Ok, that looks fine. How is the size argument set? Could that possibly go out of scope or be overwritten by something else, if you only see this error occasionally?

If not, I think we will need a project to reproduce this, in order to help you further.

[NickH]

Jorgen,

I have uploaded a project called flash_test_usb which is a combination of usbd_acm_acm and flash_fstodare sample projects.  There is some log output to USB for debug.

When the code is run on the DVK, all works well.  When the code is run on a custom board, it works fine in debug using Segger via the DVK but when run on its own, the code fails with ret code 16 after the first call to nrf_fstorage_erase.  The code is installed using nrfjprog after an --eraseall.

Checking the flash memory location for the failing erase reveals page is currently empty

nrfjprog -f NRF52 --memrd 0x3f000 --n 8

0x0003F000: FFFFFFFF FFFFFFFF                     |........|  

If I run the same code on custom board via debugger, code runs ok and same call yields:

nrfjprog -f NRF52 --memrd 0x3f000 --n 8

0x0003F000: 6C6C6548 0039206F                     |Hello 9.|

Nick

flash_test_usb.zip

[Jørgen Holmefjord]

Hi,

Is the project supposed to be run with a softdevice? I'm not able to compile it due to NRF_SUCCESS not being defined in nrf_nvic.c. I tried to remove this file, but it seems that the project also does not load softdevice automatically, even if the flash/RAM and fstorage backends used suggests that a softdevice should be included.

I modified the project to not use a softdevice, but if you require a softdevice, I can also test with that.

Best regards,
Jørgen

[NickH]

It should work with soft device  - I removed nrf_nvic.c  and nrf_soc.c and then this error disappears (cf. https://devzone.nordicsemi.com/f/nordic-q-a/43085/nrf_success-undeclared-first-use-in-this-function-did-you-mean-nrfx_success).  

[Jørgen Holmefjord]

Yes, I did that as well. I was able to test it both with and without softdevice on the DK. I'm assuming that you mean nRF52840 DK when you write DVK, and that you are not able to reproduce the issue on this either?

Can you think of any difference between your custom board and the DK that could help explain this?

[NickH]

Yes - nRF52840 DK.  I'm at a loss to think of what might cause the difference since clearly the nRF52840 modules on the DK and the custom  board share the same basic memory footprint.

I also don't see this issue on the DVK and code runs both with and without debugger.  Code runs fine on custom board with debugger but not standalone.

What sort of differences might be responsible?

[NickH]

I have tried some further debug.  I changed the sample project to use the fds API's rather than writing directly to flash as per the 'flash_fds' example.

I have noticed the following:

 - the code will run on the custom board after being downloaded via debugger using SWD pins

 - after running OK in debug mode, code also runs OK and flash accessed correctly even after a board reset

 - however, if power is cycled to the custom board, code then runs until any kind of flash access attempted wherein a invalid address message is seen

- if code is downloaded via nrfprog (after chip erase), code only runs after power to chip cycled. 

 Q - what is different between a reset and a power cycle in terms of flash?

This flash behaviour is NOT seen on DK when 52840 run isolated from rest of DVK so it must be something different on the custom board...