• State Not Answered
  • Replies 6 replies
  • Subscribers 5 subscribers
  • Views 357 views
  • Users 0 members are here
Options
Related

Issues with Loading Custom Secondary Bootloader via DA14531 ROM Bootloader

Ahmad2448
Hello Renesas Community,
We’re currently developing a custom secondary bootloader for the DA14531, which we intend to load from SPI flash via the ROM bootloader. However, we're encountering an issue. It appears that while trying to load the secondary bootloader, either:
  1. There’s some form of memory corruption occurring, or
  2. The ROM bootloader refuses to load our custom secondary bootloader.
We are facing challenges to debug due to limited visibility into the ROM bootloader’s behavior. If anyone can help answer the following questions, it would be greatly appreciated:
  1. RAM Usage and Limitations:
    • Which sections of RAM can safely be overwritten by our secondary bootloader, and which should remain untouched during loading?
    • What is the maximum size our secondary bootloader can occupy in RAM? If our bootloader exceeds this maximum size, will the ROM bootloader detect this from the Multipart Header and reject the load attempt immediately? Is there a way to confirm this behavior through debugging?
  2. ROM Bootloader Insight:
    • Is there a way to view or better understand the ROM bootloader code for the DA14531? Any level of detail would help us identify potential conflicts or requirements we may have overlooked.
    • Does more detailed documentation exist for the DA14531’s ROM bootloader, specifically regarding constraints, error handling, and expected behavior during loading? We have reviewed the available documentation, such as the SUOTA Overview, it provides limited details for our case.
Any insights, especially around memory mapping and how the ROM bootloader verifies images, would help us identify the issue we are facing.
If someone has worked on the similar application and didn't face any issue, kindly let us know how they handled the memory mapping.
Thank you in advance for any guidance!
Parents
  • 0

    Hi Ahmad,

    What kind of second bootloader you want build?

    Does this project can help which is in the SDK path:

    DA145xx_SDK\6.0.22.1401\utilities\secondary_bootloader

    BR,

    JH_Renesas

  • 0 in reply to JH_Renesas
    Hi JH_Renesas,Thank you for your response.
    We are already using the mentioned bootloader example. I’d like to provide a bit more context about our setup:
    We’ve developed a simple example firmware for the USB stick devkit that blinks an LED upon a successful load. Our setup includes a custom second-stage bootloader with the following sections defined in RAM:[SECTIONS IMAGE IN ATTACHMENT]
    Section Explanations
    • LR_IROM1, LR_IROM2: Defined in the SDK.
    • LR_IROM3_SYS: Contains code that will be overwritten during bootloading (e.g., startup code, BLE, and OTA protocol).
    • LR_IROM3_BOOT1: The boundary for firmware image size, ensuring this section is protected from being overwritten by the bootloader. Containes first part of the bootloading code and data.
    • LR_RETAINED_RAM0: Same as defined in the SDK.
    • BLE_EXCHANGE_MEMORY: Protected area not used by the bootloader, dirtectly, probably only used in OTA mode by the BLE stack.
    • LR_IROM3_BOOT2: Used for bootloading code and data.
    • LR_RETAINED_TRNG_STATE: Same as SDK.
    • ROM_DATA: Identified by reverse engineering the ROM image, which appears to be used by the ROM bootloader for storing data. (We lack public documentation on this, so our understa
      nding may be incomplete.)
    We also have the ROM bootloader, which we refer to as the first-stage bootloader.Behavior with RAM Loading
    When the second-stage bootloader is loaded into RAM via SWD, the boot process works as expected:
    • - In this setup, there is no multipart header in the flash, only our custom header at a defined offset, followed by the firmware (blinky).
    • - The flow is straightforward: Second-Stage Bootloader -> Firmware, and the LED blinks successfully, indicating the firmware is running.
    Issue with Flash Loading
    When we store a multipart structure in the flash, however, the boot process fails. The structure is as follows:
    1. Multipart Header [0-7]
    2. Second-Stage Bootloader [8-N]
    3. Firmware [N+1-O]
    4. Empty Bank [O+1-P]
    5. Second-Stage Bootloader Configuration [P+1-END]
    In this setup, the expected flow is: First-Stage Bootloader -> Second-Stage Bootloader -> Firmware. However, the boot process fails at this stage.Additional Notes
    • Our custom second-stage bootloader was developed using the SDK second-stage bootloader as a reference.
    • The bootloader includes OTA functionality, requiring a split in memory: the Sys/OTA section (to be overwritten during firmware loading) and the Bootloader sections (which remain intact). The bootloader uses flash configuration values to determine whether to boot the firmware or enter OTA mode (with a BLE service exposed for OTA).
    • When loaded directly to RAM, all functionality—including OTA packet reception and image writing to flash—works as expected.
    Possible Causes
    Based on our tests, we suspect:
    1. Size Limitation: The ROM bootloader might reject our second-stage bootloader if it exceeds a certain size.
    2. Memory Corruption: While the ROM bootloader loads the second-stage bootloader, some memory corruption may be occurring, causing undefined behavior or exceptions.
    Thank you again for your time and assistance. We’d greatly appreciate any insights or suggestions you and your team might have in resolving this issue.
    Looking forward to your reply.



    Attached Image:


  • 0 in reply to Ahmad2448

    Hi Ahmad,

    Did you have tried with the latest SDK V6.0.22.

    Please let me know if you done the test and is there any reason why you are still using the old SDK6.0.16

    BR,

    JH_Renesas

  • 0 in reply to JH_Renesas

    Hi JH Renesas,

    We haven't tried with the latest SDK V6.0.22 yet.
    We are currently facing issues with the ROM Bootloader. I am not sure if the latest sdk will resolve it.
    But I will test with the latest SDK and get back to you.

    It would also be good to know if we have any size limitations or which RAM sections can be overridden, and which should not be touched while loading?
    What's the maximum size in RAM our secondary bootloader can have?

    Best Regards,
    Ahmad
  • 0 in reply to Ahmad2448

    Hi Ahmad,

    Our team has following this question via email, thanks for your questions.

    BR,

    JH_Renesas

Reply Children
No Data