CC2340R5: Bluetooth forum

Hello Clement,

As mentioned in the previous thread, I intended to use the Serial ROM Bootloader (SBL). However, since DIO6 is not exposed on my custom PCB, I am unable to utilize the default SBL configuration.

To address this limitation, I plan to modify the MCU Boot application (currently used for the OAD application) to implement custom commands for firmware updates over UART.

Could you please provide guidance on how to approach this modification? Additionally, if there are any references, documentation, or examples that I can use for this purpose, I would greatly appreciate it.

Thank you in advance for your support!

Hi, 

Understood, thank you so the context. 
If I may, I m not totally sure this approach is the most optimal to work around the limitation we discussed in the other thread. 
The limitation we have discussed implies that *if the device is blank* you are forced to use a UART configuration that is not possible for your design. Here you are looking at modifying MCUboot - which has to be flashed on the device. If you have a way to flash MCUboot, I guess you have a way to flash a valid CCFG (and select another UART configuration for the serial bootloader). 
Maybe I have missed something, let me know. 

Also, I may seems « pushy » for using a proper bootloader (either ROM or Flah based). I am doing this because I genuinely think this is the approach that will offer the more efficient, customizable and reliable solution. I’ll be happy to help you in other directions, but I believe my job is to also provide my inputs on the system design. Hope you don’t mind :)

Best regards, 

Hello,

Thank you for the response.

I am currently unable to write the CCFG file because, initially, I can flash the module using Uniflash in the production jig. However, once the module is deployed in the field, I only have UART available to update the firmware.

When using the ROM bootloader and attempting to update the firmware over SBL, the process first erases the entire flash. After this, I can provide the CCFG and user application using the Linux SBL tool. If the update fails during this process, there is no way to revert to the default configuration, as DIO6 is not available in the custom PCB.

My requirement is similar to the OAD application. When an OAD update fails, a persistent application is still available, which allows for firmware updates over the OAD service.

I want to utilize UART in the same way that the OAD service is used for firmware updates. This may require modifications to the basic_ble_oad/Persistent or MCUboot application. I am seeking guidance on the best approach to update the firmware over UART in the basic_ble_oad project, ensuring that if the update fails, it can be restarted.

Hi,

Thanks for the details. Fair points I did not think about in the first place.

To your question, MCUboot is initially thought to boot the device on the right image, not to receive the image.
You will for sure manage to extend MCUboot functionalities to get the image received over UART, but is it really what you want to do? This means you'll have to reset the device and signal to MCUboot you want to receive an image. I guess this can be done at the begining of the MCUboot execution where the status of a pin can be checked. Alternatively you could rely on a Flash variable (or persistent RAM) set right before reset.
Last element, MCUboot image is not meant to be updatable. Adding more code in it, then should be carefully thought through - reverse argument, is that code space in MCUboot is less limited than in the rest of the application.

The other option is to get the image reception code within the application - i.e. basic_ble_oad project. To me, the risk in that case is that you should absolutely ensure that only one image is received at the time. 

I hope this will help,

Best regards, 

Hello Clement,

Thank you for your detailed response and insights. Your points have helped clarify the nuances of using MCUboot versus implementing the firmware update logic in the application.

To move forward, I’d appreciate your validation and guidance on the approach I’m considering:

1. Example Code or Reference
   Are there any example projects or code references available for implementing a device firmware update over UART (other than using the serial ROM bootloader)?

2. Proposed Approach
   As per your input, here’s my proposed workflow:

   • In the basic_ble_oad application, I will implement logic to detect a specific byte on UART.
   • On receiving this byte, I plan to set a persistent flag or variable in flash.
   • After setting this flag, the device will restart and boot into a persistent application.
   • In this persistent application, I will implement the logic to receive the new firmware over UART and write the image data to the location where the current basic_ble_oad application resides.
   • Once the complete firmware image is written, the device will reset and boot into the new basic_ble_oad application.

3. Guidance on Flash Management

   • Could you provide insights on where and how to set the persistent data in flash to signal the bootloader or persistent application to start UART-based firmware reception?

4. Firmware Writing APIs and CRC Validation

   • If I proceed with the above approach, could you guide me on the APIs or references to:
     • Erase the current firmware section.
     • Perform CRC checks for data integrity.
     • Write the new firmware image data until the transfer is complete.
       
       

I’d greatly appreciate your validation of this approach and any references or best practices you could share for implementing these steps.

Thank you for your continued support!

Hello Experts,

Please provide the guidance on above query.

This is urgently required by my metering client in India.

Thank you.

Hello,

I am currently implementing the image download over UART feature in the persistent application. However, I am encountering the error: "Program will not fit into available memory."

Here are the relevant details:

• Start Address of Persistent Application: 0x6000
• Current Persistent Application Size: 175.49 KB
• Persistent Slot Size Specified in .cmd File: 0x2BFF0

To accommodate the new feature, I need to increase the size of the persistent slot by 25-30 KB. Could you please guide me on the necessary changes required to increase the size of the persistent slot while ensuring that other memory slots do not overlap?

Specifically, I would like to know:

1. What changes are needed in the linker command file (.cmd) or equivalent configuration to adjust the slot size?
2. Any updates required in the project settings or memory layout configurations to prevent overlap with other slots.
3. Steps to validate and test the updated memory configuration.

Your assistance will be greatly appreciated as this adjustment is critical for implementing the UART-based DFU feature in the persistent application.

Thank you for your support!

Hi, 

As your last question is not totally related to the initial discussion, I have answered your question in a separate thread https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1459716/cc2340r5-bluetooth-forum---persistent-application-does-not-fit-available-memory?tisearch=e2e-sitesearch&keymatch=%2520user%253A623668# 

Best regards,