• State Verified Answer
  • Replies 15 replies
  • Subscribers 65 subscribers
  • Views 388 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328095
Options

i2s peripheral not generating pointer update events when MCUBoot enabled on nrf5340 device

responsible_duck

Hello,

As soon as we enable CONFIG_BOOTLOADER_MCUBOOT and have an operational MCUBoot image, we noticed that our audio pipeline is no longer working for our i2s omni-microphone. Specifically we fail to allocate buffers. When we pull out the bootloader configuration it works again. This is on 2.6.1 of the SDK / toolchain. After days of debugging this is what we found:

The reason for the audio errors is that the I2S peripheral is not generating pointer update events, so the ISR is not refreshing buffers and our audio thread times out after 2 seconds. We have some PDM mics as well which do not have an issue on a similar audio processing stack; it's limited to I2S. And we don't suspect anything with the I2S mic itself, as the nRF I2S peripheral generates the clocks - even if there was no mic connected, things would still run. Looked extensively at the driver changes in 2.6.1 and nothing stood out. Copied over the 2.5.2 I2S drivers into 2.6.1 and that didn't help.

Also copied the nrfx drivers from 2.6.1 into 2.5.2, and used the pre-2.6.1 FW, and that still worked.
Messed around in the debugger on the working and non-working builds and we can reproduce the behavior by poking registers, so I'm not suspecting runtime issues (though could possibly be init). We backed out bootloader, staying with SDK 2.6.1, and things work again.
But we need to get MCUBoot and the audio pipeline working. Please we are so close. So here are some questions:
  • Could this be related to enabling the internal 32 khz clock RC for mcuboot? (ie CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC and CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM)
  • Are there any hardware inits in bootloader, specifically with clocks or voltage, that may affect the running image?

Here are some things we're thinking of trying next but its a bit of a rabbit hole:

  • I don't think the symptoms indicate any pin conflicts, but check if there are any leftover configs in bootloader.
  • Is it possible to enable bootloader in 2.5.2 with older FW, just for comparison?
  • Can you hack bootloader to skip most of its operations and just transfer to the main image?
  • Is NET processor being initialized, and causing some side effect?
  • Leftover flash, or some memory layout issue which is causing second-order effects?

For reference of our configuration files, you can see here:  nRF5340 Custom Board App not booting when enabling CONFIG_BOOTLOADER_MCUBOOT 

Parents
  • 0

    We narrowed it down to serial recovery being enabled:

    `CONFIG_MCUBOOT_SERIAL=y`
    With MCUBOOT enabled and `CONFIG_MCUBOOT_SERIAL=n` in the `child_image/mcuboot.conf`, our audio pipeline via i2s works fine. However, we need serial recovery mode enabled. 
    Any insight as to why this would cause i2s to fail?
  • 0 in reply to responsible_duck

    Hi,

    Glad you were able to resolve this. I were about to reach out to you regarding setting the serial config to n based on some input from my colleagues but it got lost when I were trying to find the reason for why this would be the fix.

    From what I were able to uncover after discussing with my colleagues it seems to be caused by something in the cleanup after booting causing this configuration to make it so that some GPIOs still are in use. I will see if I can find more information regarding this or if it has been patched in the soon-to-be-released V2.7.0, but for now this is alteast whats causing it.

    Kind regards,
    Andreas

  • 0 in reply to responsible_duck

    Hi,

    responsible_duck said:
      I think I want mcuboot to just use the same overlay as my main app so that pins do not conflict. Is that possible? If so, how can I do it?

    Yes, this is correct. You will have to add a child image overlay file for any multi-image build to ensure that all parts uses the same configuration.

    To ensure that MCUboot uses the same overlay as the application in NCS, you need to provide overlays for a child image (e.g. MCUboot) using its own overlay file. The build system automatically applies any device tree overlay located in the child_image folder provided you follow the schema (e.g. <project_root>/child_image/mcuboot/boards/nrf52840dk_nrf52840.overlay).
    For example, if you have specific configurations for your application, you should put the overlay of your board inside the boards folder. This way, the relevant parameters to build MCUboot correctly to work with the chosen application will be passed automatically to the MCUboot build system so they are in concert with each other.
    Also, make sure to set in your parent image conf CONFIG_BOOTLOADER_MCUBOOT=y to signify it will be chain loaded by MCUboot.
    For more information regarding multi-image builds, you can refer to the documentation:
    responsible_duck said:
    This seems to work for our app but I think mcuboot only picks up the common dts configurations and not the custom board overlays? Why is that even though it is built together with the app?

    There are two options that could cause this, the first is that not all images are not using the same overlay, and the second is that you're building for a board that has a slightly different name than the overlays name.

    The current build system chooses devicetree files based on the build targets name, meaning that if you build for for instance "nrf52840dk_nrf52840" it will use the "nrf52840dk_nrf52840.dts" from zephyr/boards as well as any "nrf52840dk_nrf52840.overlay" in your project folder. If your build target is "nrf5248dk_nrf52840_custom", it will look for any overlays that ends with "_custom" in your project folder, meaning that if you have a "nrf52840dk_nrf52840.overlay" will be ignored since it is looking for the overlay ending with "_custom.overlay" (unless you specify this as a Kconfig fragment when building).

    To summarize: Your overlays needs to have the same naming convention as your board/build target.

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Thanks this is helpful! If we have multiple .dts files or boards in the child_imgage/mcuboot/boards/ folder, how do we choose the board configuration in VS Code? For example, for the main app we can simply select board and add any overlays...

  • 0 in reply to responsible_duck

    Hi,

    Happy to hear that!

    I believe that lesson 3 in https://academy.nordicsemi.com/courses/nrf-connect-sdk-intermediate/ should address some neat tips and tricks w.r.t custom boards (I could be wrong), but that is unfortunately all I could manage to find before the weekend. If you could have a look at that/those topics until I look further into this during the start of next week and let me know if this answers your question or not, that would be great

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi Ever,

    Apologies for the long response time since last you heard from me... 

    Could you give me an update w.r.t your status? Are you still seeing issues with selecting child images?

    Regarding your question: This should be explained in https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/multi_image.html, maybe more specifically the section regarding enabling the child image: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/config_and_build/multi_image.html#defining_and_enabling_a_child_image 

    responsible_duck said:
    child_imgage

    Just for sanities sake, if there is a typo in the repository's name, then the build system may not recognize this as a child_image repository and thus may be struggling with finding which child image it should select. If it's named properly then the build system typically does find what it needs based on your build target and configurations in the child_image repository if you have a child image there

    Kind regards,
    Andreas

  • 0 in reply to AHaug

    Hi thanks for the advice!

    Our solution was to duplicate the `.overlay` files from the main app into the `child_image/mcuboot/boards` path. The i2s line now starts normally and we can use it to transfer audio data. 

Reply Children
Related