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]

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...

[Jørgen Holmefjord]

NickH said:

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

I can't think of any particular difference between these two operations.

NickH said:

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

Do the code not run if you reset the board from nrfjprog?:

nrfjprog -r