NCS nRF91: using PRS after mcuboot used SPI

Hi,

we are using an nRF9160 on a custom board with NCS 1.8.0. I have been able to reproduce the following behaviour with a nRF9160 DK 1.0 and NCS 1.9.1

For our application, we need mcuboot to have its secondary on an external SPI flash. We use SPI3 for that and of course configure it for mcuboot in its device tree.

In our main application, we need 3 UARTs (we use UART0,1,2) and on the "3" block, we need to use SPI and I2C "simultaneously" using PRS with the nrfx drivers. Of course that SPI3 and I2C3 are not running at the same time, but they get initialized, used and deinitialized consecutively. just one time it's a spim3 and one time it's a twim3.

But some strange problems start to occur, when using the function block 3 slightly different. 

If you init the spim/twim as "blocking", i.e. without a callback function for events, and initialize, transfer and deinitialize consecutively, everything seems to work fine. 

But when I want to use a callback function, I get a fault at runtime. 

void main(void)
{
  printk("Hello World ! %s\n", CONFIG_BOARD);

  eErr = nrfx_spim_init(&sSpimInstance, &sDevCfgSpim, NULL, NULL);
  eErr = nrfx_spim_xfer(&sSpimInstance, &sSpiRxTxData, 0); /* xfer necessary to get crash */
  nrfx_spim_uninit(&sSpimInstance);

  eErr = nrfx_twim_init(&sTwimInstance, &sDevCfg, Main_EvtHandler, &sTwimInstance); /* crash */
  nrfx_twim_enable(&sTwimInstance);  
  nrfx_twim_uninit(&sTwimInstance);
}

I always seem to crash at this function it looks like: __STATIC_INLINE void __NVIC_EnableIRQ(IRQn_Type IRQn),that wants to enable the interrupt for that function block for the callback.

I only seem to get these crashes when I use SPI3 also for the mcuboot flash access. For the MCUBOOT I obviously have the SPI3 "activated" in the device tree, while in my main application, i have it disabled in the device tree. My guess is, that MCUBOOT marks something somewhere, that the regular application cannot unmark or something, when just using nrfx drivers and not devicetree-zephyr-stuff.

When the Function block is used to do one thing, the other seems not to work anymore. Likewise I get a crash when using certain functions "between" the xfer and the deinit like so:

void main(void)
{
  printk("Hello World ! %s\n", CONFIG_BOARD);

  eErr = nrfx_spim_init(&sSpimInstance, &sDevCfgSpim, Main_TestEvtHandlerSpi, NULL);
  eErr = nrfx_spim_xfer(&sSpimInstance, &sSpiRxTxData, 0);
  k_sem_take(&sMain_Sem, K_MSEC(500)); /* crash */
  nrfx_spim_uninit(&sSpimInstance);
}

This does not seem to be related to the SPI3 being used by MCUBOOT, but it's frustrating nonetheless.

I have attached a project for the DK that reproduces the fault. 

It would be interesting to see, if there's a way to make this work, since ti is crucial to our project.


1033.hello_world_twim.zip

Parents Reply Children
  • Hi Dejan,

    I know. As I said, we use the other function blocks for uart0, uart1 and uart2. The last function block then is used via PRS
    developer.nordicsemi.com/.../README.html

  • What board do you use? nRF9160dk_nrf9160_ns or nrf9160dk_nrf9160? I tested it with nrf9160dk_nrf9160_ns  and then it failed in \bootloader\mcuboot\boot\bootutil\src\loader.c-->boot_read_image_headers(). I then tested with the nrf9160dk_nrf9160 and noticed that it failed in drivers\flash\flash_page_layout.c--> flash_page_foreach(). I used NCS v1.9.1

    I confirmed this by setting breakpoints before and after these functions and saw that it didn't hit the breakpoint.
    I'm not sure how you saw that it failed in  __STATIC_INLINE void __NVIC_EnableIRQ(IRQn_Type IRQn). Could you provide some detailed steps how to reproduce?
    Next step would be to add some RTT/UART logging to see if we can get any hard fault information. I will try to do this and get back to you with my results.
    Best regards,
    Simon
  • Ah, I figured out why it failed for me. After enabling log I saw the following:

    E: SFDP magic 00000000 invalid

    Which comes from the spi_nor driver and means that I'm not able to communicate with external flash

    That is why it failed in boot_read_image_headers(), since it tried to acces the image in the external flash. The reason it failed was because but I hadn't programmed the 52840 properly, the 52840 works as a board controller and will connect the external flash to the 9160.

    After programming the nrf9160dk_nrf52840 with connect_ext_flash_to_9160 I no longer had this issue. Now I will look into your issue.

    Best regards,

    Simon

  • After fixing the first issue a new popped up:

    I: MX25R64: SFDP v 1.6 AP ff with 3 PH
    I: PH0: ff00 rev 1.6: 16 DW @ 30
    I: MX25R64: 8 MiBy flash
    I: PH1: ffc2 rev 1.0: 4 DW @ 110
    *** Booting Zephyr OS build v2.7.99-ncs1-1  ***
    I: Starting bootloader
    I: Swap type: none
    E: Unable to find bootable image

    Do you not get this?

    I can see that it fails to validate the primary slot, since both of these statements evaluates to true. Do you know why it fails here, since you don't see it on your side?

    It is probably something obvious. I will continue to investigate this tomorrow, so I can reproduce the issue you see.

    Best regards,

    Simon

  • Hi, sorry for taking so long to reply.
    1. yes, I am using the nRF9160dk_nrf9160_ns.

    2. your problem is most likely due to this:  Invalid private key with ed25519 

    I have changed this in my SDK installation, so of course it works. so It's my bad.

    In my sample project you just need to change signature type to RSA instead of ED25519 in nRF_mcuboot.conf. That should fix it.

Related