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

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

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

  • 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

  • I am doing a full erase before flashing. I am passing the defines to the API:

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

    The Assert that fails is:

    NRF_FSTORAGE_PARAM_CHECK(addr_is_within_bounds(p_fs, src, len), NRF_ERROR_INVALID_ADDR);

    The full project is a bit cumbersome - I will create a smaller project that duplicates the issue using USBD to log the output.  Where should I upload?

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

  • #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,
      
    };
  • 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.

Related