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.

Bootloader Implementation Question F28035

Other Parts Discussed in Thread: CONTROLSUITE

Hey all,


This falls under the umbrella of a general question about the bootloader.  I was wondering about a few particular details and I didn't come across an answer in any documentation I had found. 

1) When booting from external EEPROM using the bootloader is it assumed that the linker file is written to configure the MCU to run out of RAM only?  My thinking is yes, but I couldn't find a definitive answer.

2) If the bootloader fails the micro will attempt to boot from flash.  Would you normally produce a version of code to boot from Flash which would also setup the OTP registers to boot from an external device?  I'm not really sure what limits or requirements are placed on the backup code in Flash, or how to best set the OTP registers.

3) Looking through the bootloader/boot ROM documentation in controlSUITE (C:\ti\controlSUITE\libs\utilities\boot_rom\2803x\2803x_boot_rom_v1\source\).  I looked at the code provided for example I2C_Boot.c.  Would the project you're compiling actually need to include the C code provided to setup the I2C bus?  I thought the bootloader would bypass the need to write C code for configuring the I2C module.  Or would that code go into the backup Flash image? I'm just a little confused about the code examples provided and what the purpose is.  I thought you just needed to create a program that runs from RAM, and run the hex2000 utility to create the required hex file.

Just looking for some clarification on these points. 

  • Lance,

    on #1> yes. For example you could build the blinky/GPIO toggle example to link and run from RAM and load the hex file (COFF to hex using Hex2000) in the EEPROM and set the device to I2C Boot or SPI Boot. On power up or after a reset the device will load the example/app from EEPROM onto the device RAM and run it.

    Any standard control suite example when built to run from RAM can be used, so the default provided RAM linker command files should be good start.

    on #2> yes, in the I2C or SPI EEPROM boot modes, the MCU comes up as master sends out clock and if there is no response it assumes that there is no EEPROM and tries to default to flash. It is upto the customer on what he programs in flash, a default application or an application that re-attempts the boot over other peripheral or same SPI/I2C.

    I'm not sure what you are asking about the OTP registers? which registers you are talking about? the OTPKEY and OTP BOOT MODE registers?

    on #3> The boot ROM sources are provided for reference, you can use the ADD symbols option from the CCS and point it to the OUT file in the ROM sources and that should enable the source level debug of the ROM code and understand it better. The ROM loaders intialize the peripheral for boot.

    If you want to call back into the ROM functions from flash then you need to find the proper API. For ex: I2CBoot function in ROM initializes the GPIO and the I2C peripehral as well. But if you want to configure the peripheral in the flash application and just call the helper functions from ROM that should be possible as well.

    Hope this helps, please let us know if you have further questions.

    Best Regards

    Santosh Athuru

  • Santosh,


    Thanks for the detailed response.  That answers most of my questions.  When I spoke of the OTP registers I did mean the OTPKEY and OTP BOOT MODE registers.  I was wondering if there is a recommended way to set the values stored in both.  I wouldn't want to make a mistake since it can't be changed.

    Best regards,

    Lance