This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2340R5: CC2340R5 - OAD bootloader check

Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH, CC2642R,

Hi Ti Team,

The CC2340 OAD included application every time while waking up the bootloader compares the Persistent(Image A) & Image B(Application image) for 4 secs this consumes 3.2mA of current. I have attached the screenshots for your reference. 
I checked with the default example image that comes with the sdk and it does the same thing.

In the CC2642 OAD we didn't see that bootloader check happening for 4 secs. It takes less than a second and this much power consumption won't happen for every wakeup.

SDK used -  simplelink_lowpower_f3_sdk_7_10_00_35
CC2340 IC used - Latest Samples.
Could you please clarify whether this is how the CC2340 ble SDK itself performs or if I am doing anything wrong here. Because this is increasing the avg consumption of our system.
Let me know if you have any questions.
Thanks,
Nambirajan R
  • Hi Nambirajan,

    Thank you for reaching out. We will look into your questions and get back to you as soon as possible. In the meantime, can you specify if you are using an LP-EM-CC2340R5 board for your testing or a custom board?

    Best Regards,

    Jan

  • Hi Jan,

    We are using an custom board for testing.

    Thanks,

    Nambirajan R

  • Hi,

    Thank you for reaching out. I will have to request you a few more details so I can understand better the way you are using the example.

    - May I kindly ask you to describe the way you have prepared the images and flashed the devices?

    - Could you please specify the MCUBoot settings you have selected? Such settings should be in the MCUBoot project in mcuboot_config/mcuboot_config.h. Please also specify if you have enabled logging and GPIO blinks in the MCUBoot project

    In parallel, I have started a discussion thread with the team responsible for the development of this component.

    Best regards,

  • Hi Clement,

    I just follow the same way of creating on-chip OAD images in cc26x2 without changes in the configurations of OAD functions. We need to use the MCUBoot and flashed the images with the uniflash application on the specified memory locations. For MCUBoot.hex address as auto, for persistent.bin 0x6000, for image B.bin at 0x32000

    I Tired loading the MCUBoot at default configurations without changing any files include mcuboot_config.h and by excluding the GIPO's I didn't changed the logging part. Also I have tried with the hex file of MCUboot is in the SDK by default.

    Let me know if you have any questions.

    Thanks,

    Nambirajan R

  • Hi,

    Thank you for the details provided.

    In order to find some optimizations possibilities, I would recommend to run the MCUBoot code in debug mode and understand why the two images are reviewed at each boot. This may be because the CRC or the version number of the two images is not as expected.

    As mentioned before, I continue collecting inputs for your case with internal teams. Please bear with us.

    Best regards,

  • Hi,

    One element  I omitted, I recommend reviewing the MCUBoot documentation describing the operations executed at boot time: https://docs.mcuboot.com/design.html 

    Best regards,

  • Hi Clement

    By disabling the GPIO debug I could reduce that checking period from 4secs to 2secs. I tried running my custom board in debug mode there mcuboot fails always. It seems like the application could not start while I am running in debug mode. 

    If the image version are crc is incorrect it should not start the application image or during OAD process it should fail right that things are happening fine for me.

    The MCUBoot design configurations looks fine when comparing with this design file.

    Let me know if you have any questions.

    Thanks,

    Nambirajan R

  • Hi,

    Good to see disabling debugging could reduce the execution time by 50%.

    With this improvement, do you meet your system's requirements? 

    Best regards,

  • Hi Raja,

    Thank you for your patience. We have looked further in your question, and it seems the behavior you are observing when disabling debugging is correct.

    - MCUBoot will perform full verification over the images at each boot

    - The execution time of MCUBoot on CC2340Rx is longer than the execution of TI BIM on CC2642R for the following reasons

    • CC2340R5 does not use an ECC hardware accelerator (CC2642R has such accelerator)
    • MCUBoot execution time may be affected by the images sizes
    • On the same device, MCUBoot takes slightly more time than TI BIM to execute. In exchange, MCUBoot offers feature not offered by TI BIM (Note: TI BIM is NOT available for CC2340R5 at the moment) 

    I hope this will help,

    Best regards,