TMS320F28388D: Programmatically Switch Booting between Flash Sectors

Hi Jay,

The boot locations on reset are decided by the bootROM. Were you able to see the boot ROM Flash Sectors in the TRM?

Thanks,

Charles

Hi Charles,

I have only been reading the documentation about how the boot sequence works to decide on a boot approach. I want to put my own bootloader into CPU1 sector 0, and have it issue a reset and then boot to sector 4 with my main code.

Jay

Hi Jay,

I'll be able to get to your question in the next day.

Thanks,

Charles

Hi Jay,

What setup do you currently use?  Is it custom board or one of TI's launchpad or control card?  Reason I ask is because this involves writing BOOTDEF and BOOTPIN values to the OTP and this process would be permanent in that once those OTP locations are written to, there is no going back.  You would also need access to dedicated GPIOs that would be used to map to the available flash sector entry points.  For example, if you need to switch boot from sector0 and sector4, you need to dedicate 1 GPIO pin, or if you need to switch between sector0, sector4, sector8, or sector13, you need 2 GPIO pins.

You can first try this with EMUBOOT and EMUBOOTPINCONFIG before writing to OTP.  Let me know if this option is good for you and I can describe the process.

Regards,

Joseph

Hi Joseph,

Writing to OTP is what I am trying to avoid. Can EMUBOOT and EMUBOOTPINCONFIG override normal boot flow? According to the documentation, the way those registers are used is if a debugger is connected to the device.

So with the GPIO, the bootloader would set the pin and hit a system reset? Does that clear out the GPIO states? How does that flow work? I have not seen a description of the device setting its own boot pins -- I assumed that was for external devices to trigger the boot mode.

This can't be the first time a bootloader changes where the next boot comes from. In other applications, I have seen jump instructions to just start executing at the desired offset. Do you think that the jump is just the simplest/cleanest way to implement this flow?

Thanks for the help,

Jay

Hi Jay,

Yes, you can use EMUBOOT  and EMUBOOTPINCONFIG for the new boot flow.  The purpose of EMUBOOT is to check it out first that the flow is correct before programming it permanently on the OTP BOOTDEF and BOOTCONFIG locations.  How EMUBOOT works is first write the EMUBOOTCONFIG and EMUBOOTDEF in memory once program is loaded with debugger connected.  You would need to manually write the values using the memory browser on the addresses below:

For EMUBOOTPINCONFIG, BOOTPIN configuration should be written on address 0x00000D00.  Refer to Table 5-10 CPU1 Standalone Boot Mode Select Pin Decoding.  For instance, you want to use 2 pins (GPIO9 and GPIO10) to choose the different flash boot entry points, you would need to write  0x5AFF0A09 to address location 0x00000D00.  Next, you need to write the corresponding BOOTDEF value 0x63432303 to EMUBOOTDEF-LOW (address 0x00000D04) .  The value is based from table below.

Depending on the binary states of GPIO10 and  GPIO9, you now have the option to boot from any of the 4 flash entry points above.  If GPIO10, 9 are both pulled low, then boot point is flash sector 0.  if GPIO10 is pulled high but GPIO9 is pulled low then boot entry point is sector 8 when play/start button is pressed in emulation (debugger connected) mode.

Once you prove this process working in emulation mode and are comfortable with it, then and only then will you program the values in OTP.  This will now use the DCSM tool in SysConfig.

Regards,

Joseph