TMS320F280039C: SCI Bootloader using SCI-B Port

Hi Ege,

I'll have to get back to you within the next day for response.

Thanks and regards,

Charles

Hi Ege,

As an update, to use SCI-B port for SCI Boot mode you will have to use a definition for SCIB_BASE , this register is located at 0x7210. 

You will also have to change the pins to be SCI-B compatible in sciPinMuxOption(). The USB-UART connection on the device shares communication lines with SCI-A by default (GPIO28/GPIO29). In changing the pins for SCI-B, you may require jumper wires to GPIO28/29 for byte transmission.

When you adjust the SCI boot mode, the device will try to use whatever GPIO mode options are in-line with USB-UART connection. 

Thanks and regards,

Charles

Hey Charles, thanks for the answer.

The thing is, we don't have anything coming out of SCI-A port therefore conencting it with jumpers to SCI-B port isn't a possibility. 

As an idea, would it be possible to add the code in the "flash_kernel_ex3_sci_flash_kernel" example to my project and make it branch to that at the start by checking a GPIO pin rather than modifying the boot mode? Would that achieve the task of rewriting the flash contents with the new program sent from the SCI port? 

Thanks.

Hi Ege,

If the boot mode remains unmodified, then the default SCI-BOOT will still use GPIO28/29 to receive data from the host programmer. 

> "make it branch to that at the start by checking a GPIO in rather than modifying the boot mode"

Do you mean if the kernel example is already loaded to the device? While it will be able to branch there, data still won't be seen on the GPIO pins as incoming from the host programmer. To check this, you can implement the branch and check the SCI-B RXBUF registers for any incoming data on the device.

Thanks,

Charles

Hey Charles,

Yes my idea was basically loading the kernel example with my application. I will try to modify that example to use the SCI-B port rather than the default SCI-A port. Then when the application start and branch to the kernel example, I will send the new version of the application (which again, including both kernel and my original application) through the SCI-B port. I think that I will use the .txt files that are used in these examples.

Would that approach has any chances of working?

Thanks.

Hi Ege,

Yes, but for the kernel example it could reside in a part of flash, if you wish to not download it every time. It seems like you are describing a live firmware update. Does this update have to be live or non-live for your project? 

Regards,

Charles

Hey Charles,

Technically no, it doesn't have to be a live firmware update. It born out of necessity, due to lack of SCI-A port on the unit. But yes downloading the kernel everytime would be redundant. 

Thanks.

By the way, I have another question regarding boot ROM code for SCI. After modifying the boot mode pins, there is an internal code that activates SCI-A port right? And this code resides in the Flash of the device at all times. 

Is there any way to modify this code piece to activate SCI-B port rather than SCI-A port and load the kernel from there?

Thanks.

Hi Ege,

One way to modify this boot ROM code would be through programming the OTP values of the device to use SCI-B port. Note, doing this would be a permanent change to the device's boot pins. 

Thanks and regards,

Charles

Hello, is there a guide or an example for this? Or an application note?

Only ones I saw were about changing the boot mode pins and which boot modes they refer to. I didn't see anything that modifies the boot code itself.

Thanks.

Hi Ege,

Modifying the bootloader code itself would require reprogramming the ROM of the device, may not be feasible to do itself. Here is a related thread on changing starting locations for the bootROM, it may be possible to change the starting location to SCI-B loader. 

(+) _c_int00 - Can this be specified so entry point is always at a specified address? - C2000 microcontrollers forum - C2000︎ microcontrollers - TI E2E support forums

Thanks,

Charles