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

Flash write issues with nrfx on nRF5340

Hello DevZone,

I am developing on nRF5340-DK v0.11.0, with nrfx v2.2.0 running with mbed Cordio, compiled with GNU make 4.3. The end goal is to make a Bootloader for the Net Core inspired by the one in the netboot example from nRF Connect.

Reading and writing to SRAM addresses works as expected. Reading from flash also works, but i get a hardfault when trying to write to the Flash of any core, from the Net Core. I am using the nrfx_nvmc driver and it chrashes in the nvmc_word_write function, as soon as the address is accessed.

I have tried using both words_write and bytes_write, all variables looks correct up till the crash when debugging, so seemingly no rouge addresses.

// Flash write address
#define TESTWRITEADDR		(NET_CORE_FLASH_BASE + (NET_CORE_FLASH_SIZE - 32))

// Test Array
static uint8_t testDat[32] = "TestData";

// Flash write function
int flash_write(off_t offset, const void *data, size_t len)
{
  nrfx_nvmc_words_write(offset, data, (len/4));
  //nrfx_nvmc_bytes_write(offset, data, len);
}

// Write call
flash_write(TESTWRITEADDR, testDat, sizeof(testDat));

The Network Core is allowed access to the SRAM (and Flash) through the SPU.

 /* Allow Network CPU access to the last RAM region of the Application CPU for IPC comunication. */
  const uint32_t permissions = SPU_RAMREGION_PERM_READ_Msk |
                               SPU_RAMREGION_PERM_WRITE_Msk |
                               SPU_RAMREGION_PERM_EXECUTE_Msk;
  nrf_spu_ramregion_set(NRF_SPU_S, 63, false, permissions, FALSE);
  
  /* Allow Network CPU access to the second RAM block of the Application CPU for Bootloader image. */
  for (uint8_t idx = 0; idx < 63; idx++)
  {
    nrf_spu_ramregion_set(NRF_SPU_S, idx, false, permissions, FALSE);
  }
  
  /* Allow Network CPU access to the Flash of the Application CPU. */
  const uint32_t flashPerm = SPU_FLASHREGION_PERM_READ_Msk |
                             SPU_FLASHREGION_PERM_WRITE_Msk |
                             SPU_FLASHREGION_PERM_EXECUTE_Msk;
  for (uint8_t jdx = 0; jdx < 64; jdx++)
  {
    nrf_spu_flashregion_set(NRF_SPU_S, jdx, false, flashPerm, FALSE);
  }

I would imagine the Net core should be able to write to its own flash by default, unless the ACL is used to block writing actions. Likewise i would imagine the Net Core should be able to write to the App Cores flash if given permission through the SPU (but not by default).

So my questions can be summarized to:

  • Am i missing something regarding the securing of the flash, or the usage of the nrfx nvmc driver?
  • Can someone point me towards a barebone example where the nrfx nvmc driver is used on the nRF5340, without Zephyr or other SDK dependencies, so i can se how securing is initialized and the driver is used?

Any help will be appreciated, thank you in advance.

Best Regards,
Torben Grann

  • Hi Torben,

    Sorry for the late reply.

    I have tried using both words_write and bytes_write, all variables looks correct up till the crash when debugging, so seemingly no rouge addresses.

    Which hardfault are you getting when doing this?

    You may need to configure the SPU to allow for data write to the region, see chapter 7.32.2 in the nRF5340 PS.

    Likewise i would imagine the Net Core should be able to write to the App Cores flash if given permission through the SPU (but not by default).

    In theory yes, the net core can have access to the app core NVMC (if SPU is configured for this), the net core then needs to write to the app core NVMC instance and enable writing. But this kind of implementation haven't been tested by us.

    Can someone point me towards a barebone example where the nrfx nvmc driver is used on the nRF5340, without Zephyr or other SDK dependencies, so i can se how securing is initialized and the driver is used?

     All the flash write samples we have are using Zephyr.

    Best regards,

    Marjeris

     

Related