LAUNCHXL-F28P65X: Slow SCI Bootloader Transfer – 16ms Delay Between Bytes

Sorry: the used command was:
./serial_flash_programmer.exe -d f28p65x -k flash_kernel_c28x_dual_ex1_c28x1.txt -a led_ex1_c28x_dual_blinky_cpu1.txt -n led_ex1_c28x_dual_blinky_cpu2.txt -b 34800 -p COM7 -v

Hi Luciano,

The 16ms inter-byte delay comes from the overhead required to read the data from COM ports on Windows. The serial flash programmer is reading the echoed back data from the target one byte at a time so this 16ms delay creates quite a loss in performance. You could try ending other tasks running on your PC except for the ones necessary for loading the kernel to the device as there may be some tasks with higher priority than the exe. Additionally, you could modify the host/kernel code to not rely on byte-by-byte verification (checksum). 

To create a flash kernel that resides in flash, you'll have to start by modifying the linker cmd file to place the appropriate sections in flash. You can refer to 28p65x_flash_api_lnk_CPU1.cmd in C2000Ware_Install_Location\C2000Ware_5_04_00_00\device_support\f28p65x\common\cmd. You can place the kernel in any of the banks available to CPU1 based on your desired behavior.

Some other questions to consider when converting the existing flash kernel to a flash-based application:

• Do you want the flash kernel to execute once the device boots? Or do you want some other application to execute on startup and the kernel will only execute when a firmware update command is received?
• Where do you want the application to reside?
• Do you need to perform live-firmware upgrades? Or offline?

If you give me some more details on your desired behavior, I can provide more guidance. 

Kind regards,

Skyler

Hello Skyler,

Thank you for your response.

So, you are suggesting that the delay is caused by the operating system rather than the host application and that I could mitigate this issue by bypassing verification and sending bytes without reading the port.

In my current system, the flash kernel always executes at startup with a timeout, so I want to maintain this approach. Since I am new to the Texas Instruments environment and bootloader development, I plan to make progressive changes.

I believe I need to program the flash kernel in a separate bank from the application. My idea is:

• BANK0: Flash kernel, ensuring it executes on every reset.
• Other banks: Application storage.

My next step is to program the flash using the same host application, making modifications only to the flash kernel and application command files.

Does that make sense?

Hi Luciano,

I wouldn't recommend fully bypassing a verification method, but if the byte-by-byte verification is too slow then an alternate approach could be considered. Without any sort of verification, you risk writing a bunch of garbage to your device. 

Luciano Vittori said:

I plan to modify both the flash kernel and the flash serial application to use the custom protocol already implemented in my powertrain system for compatibility.

Does your protocol mentioned here rely on the SCI communication with your host PC?

It's not a requirement to have the kernel be separate from the application, but it does make your implementation a lot easier. The next steps you described make sense, please reach out if you have any more questions!

Kind regards,
Skyler

Hello Skyler,

My protocol relies on CAN communication, but I believe that if I can make this example work as a resident bootloader, modifying the application logic later will be easier for me. My plan is to make progressive modifications to fully understand the process and ensure that everything works correctly.

I have modified the command files for the Flash Kernel and the CPU1 and CPU2 applications, but unfortunately, it is still not working.

I can successfully communicate with the host and execute commands such as DFU1, DFU2, Verify CPU1, and Verify CPU2. However, when I try to Run CPU1, the LEDs do not blink. I verified that the application is correctly programmed in Flash at 0x0A0000 (CPU1) and 0x0E0000 (CPU2), but the application does not seem to be running.

I don't know How to upload files here so I've uploaded projects on GitLab to share with you
28p65x_flash_programming_cpu1tocpu2_FLASH_28p65
28p65x_generic_flash_lnk_cpu1
28p65x_generic_flash_lnk_cpu2

Do you have any ideas on what could be causing this issue?

Thank you in advance!

Hi Luciano,

Luciano Vittori said:

My protocol relies on CAN communication, but I believe that if I can make this example work as a resident bootloader, modifying the application logic later will be easier for me. My plan is to make progressive modifications to fully understand the process and ensure that everything works correctly.

When you decide to port your implementation over to CAN, we also have similar examples for both classical-CAN and CAN-FD on this device. There are some differences in the user experience between the SCI and CAN examples, but the underlying implementation is very similar.

What behavior do you see when you send the RUN CPU1 command? Does the device branch to the expected entry address at 0xA0000? I recommend stepping through your bootloader to see if it branches to the proper address or if it hits an NMI/unexpected behavior after branching. If the bootloader branches to the correct address and then the LEDs aren't blinking, then it's likely an issue with the LED project. Does the LED project work when you load it via CCS?

Kind regards,

Skyler

Hello Skyler,
Thank you for your response.

Skyler Baumer said:

When you decide to port your implementation over to CAN, we also have similar examples for both classical-CAN and CAN-FD on this device. There are some differences in the user experience between the SCI and CAN examples, but the underlying implementation is very similar.

Yes, I plan to explore those examples later as I progress in my implementation. Right now, my priority is to make this example work as a resident bootloader so that I can fully understand the process before transitioning to CAN.

Skyler Baumer said:

What behavior do you see when you send the RUN CPU1 command? Does the device branch to the expected entry address at 0xA0000? I recommend stepping through your bootloader to see if it branches to the proper address or if it hits an NMI/unexpected behavior after branching. If the bootloader branches to the correct address and then the LEDs aren't blinking, then it's likely an issue with the LED project. Does the LED project work when you load it via CCS?

I started a debug session and placed a breakpoint at the end of the Flash Kernel execution. At that point, the entry address is correctly set to 0x0A0000.

    return(EntryAddr);

Hi Luciano,

Luciano Vittori said:

However, since this is a Flash Kernel debug session, I lose visibility of what the code is executing after this jump.

You can load the symbols associated with the LED blinky example to see what is happening when you branch to 0xA0000. Load -> Load Symbols -> select the .out file associated with your CPU1 LED blinky application.

Kind regards,

Skyler