TMS320F28P650DH: Loading hex with CCS is VERY SLOW

Hang Yang

Part Number: TMS320F28P650DH
Other Parts Discussed in Thread: UNIFLASH, TMS320F28377S, TMS570LS0914, , TMS320F28069F, TMS320F28335

Hi Experts,

My csutomer is using Hex in their debug process, they found that it is very slow for CCS to load the hex file to Flash, Could you please help checking what's the issue?

It's very simple to reproduce this issue:

Import a project, for example, adc_ex1 of F28P650
Switch to Flash build
Enable Hex2000 utilities in proejct properties, leave all settings as default
Build the project, debug, and load the hex file

Then you may see how slow it is loading hex compared with loading .out

Regards,

Hang

2 months ago

0 Arpit Varahmihir 2 months ago

TI__Intellectual 1410 points

Hi Hang,

Let me reproduce this issue on my end and get back to you

Regards

Arpit Varahmihir

0 Arpit Varahmihir 2 months ago

TI__Intellectual 1410 points

Hi Hang,

This is expected behavior tied to how the ASCII hex format gets loaded, not a defect specific to F28P650DH.

Root cause:

When CCS loads a .out file, the debugger reads the COFF/ELF section table directly and writes each section to flash as a small number of large, contiguous blocks over JTAG. A .hex/TI-TXT file is plain ASCII text. CCS has to parse it line by line and convert each record back to binary, and each record only carries a small number of bytes (commonly 16–32) tagged with its own address. If those records aren’t perfectly contiguous, the flash plugin ends up doing thousands of small, separate writes (and associated overhead) instead of a handful of large ones, which is why the slowdown is observed while loading it.
We’ve seen a similar pattern on a UniFlash case: the hex file was writing only 0x20 bytes at a time across widely spaced address ranges, and because there were so many discontinuous data segments, the total load time was far higher than a .out load of similar size. e.

[Intel Hex image files - generating with CCSv6 and flashing using UniFlash — https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/461531/intel-hex-image-files—generating-with-ccsv6-and-flashing-using-uniflash]
It’s also worth noting that Hex Utility settings aren’t inherited automatically the way compiler/linker options are — a default Hex2000 configuration can end up less efficient (and in some cases produce not-quite-correct output) than a manually tuned one.
[TMS320F28377S: Flash read in jtag is not the same as generated intel hex file — https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/784177/tms320f28377s-flash-read-in-jtag-is-not-the-same-as-generated-intel-hex-file]

Recommendation:
For everyday CCS debug loads we would recommend using .out directly rather than enabling Hex2000. The Hex/TI-TXT format is intended for external programming paths (UniFlash, third-party programmers, SCI/I2C/CAN serial bootloading) per the Hex Utility documentation in the compiler manual and the serial boot app note, not for CCS’s own debug-time flash loader.
[Getting Started with Bootloading on C2000 Microcontrollers (User’s Guide, SPRUJH3) -> https://www.ti.com/lit/ug/sprujh3/sprujh3.pdf — covers hex2000/C2000 Hex Utility configuration and post-build step setup for on-chip flash bootloaders.]
[Serial Flash Programming of C2000 Microcontrollers (SPRABV4, Rev. F) -> https://www.ti.com/lit/an/sprabv4f/sprabv4f.pdf — describes generating boot-format hex/TXT files via hex2000 for SCI/I2C/CAN/SPI serial boot flows, not CCS debug loads.]

You can also check out similar e2es on similar issues:

TMS570LS0914: Hex File Takes Excessive Time to Flash on Microcontroller — https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1453268/tms570ls0914-hex-file-takes-excessive-time-to-flash-on-microcontroller

TMS320F28P650DH: The generated .hex and .bin files are different after being loaded to FLASH — https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1434496/tms320f28p650dh-the-generated-hex-and-bin-files-are-different-after-being-loaded-to-flash

Regards,
Arpit Varahmihir

0 Hang Yang 2 months ago in reply to Arpit Varahmihir

TI__Expert 4256 points

Hi Arpit,

Arpit Varahmihir said:
If those records aren’t perfectly contiguous, the flash plugin ends up doing thousands of small, separate writes (and associated overhead) instead of a handful of large ones, which is why the slowdown is observed while loading it.

In the case of the example, most of the memory are continuous. This is not the case.

Arpit Varahmihir said:
CS has to parse it line by line and convert each record back to binary, and each record only carries a small number of bytes (commonly 16–32) tagged with its own address.

The reading and parsing should not be the bottle neck since this since done on Host. I've once parsed the hex to binary with a python script and it's done almost instantly.

Arpit Varahmihir said:
For everyday CCS debug loads we would recommend using .out directly rather than enabling Hex2000. The Hex/TI-TXT format is intended for external programming paths

This is no always the case. Customer has two projects, the boot loader and application. The two projects are compiled and converted to hex, and then combined into one big hex. There is also hard-coded flag added directly to the hex. By combine all stuffs in a big hex, they can load the full program to the device in the debug run. This combination can not be done with .out easily.

Which part is the bottle neck and is there anything we can do to improve it?

Regards,

Hang

0 Arpit Varahmihir 2 months ago in reply to Hang Yang

TI__Intellectual 1410 points

Hi Hang,

Regarding the bottle neck part, maybe it is ECC generation and flash-programming granularity at the hex-file splice points.

As per the TRM: Flash programming on F28P65x must be 64-bit aligned, and ECC is computed per 64-bit word tied to a 128-bit-aligned address. A .out load benefits from the linker’s ALIGN directives, so the Flash Plugin can batch ECC generation + programming into large chunks. This splice approach requires manually stripping headers/footers and is not a clean merge, which is exactly the kind of operation that can leave a handful of addresses unaligned to 64-bit/128-bit boundaries.

You can refer to the FAQ on Flash software for C2000 MCUs documents exactly this use case (combining an application and bootloader into one file), and it points at a cleaner path than manual hex splicing.

So basically, to merge two .out files into a single programmable image, TI recommends:
hex2000.exe --load_image app_1.out app_2.out --load_image:file_type=executable -o app_combined.out

This works cleanly if both projects’ linker command files are set up so their memory regions don’t overlap. The merge happens at the .out/linker level , using the same ROMS-directive-aware mechanism the linker itself uses before any hex conversion, so section alignment is preserved. You’d then run the combined .out through the Hex Utility once, as a single conversion step, to get your final hex file.
Note that while directly concatenating already generated hex/txt outputs, keep in mind:

“To combine Intel .hex files generated by hex2000: a 3rd-party tool like srec_cat would be required… the method will catenate the hex files without stripping out the necessary headers/footers. Since the headers/footers for each original .hex file are still present in the combined image, one will need to manually strip them out prior to merge in order to generate a programmable combined image.”

Recommendation
What we recommend is to try merging at the .out level with --load_image instead of splicing hex files post-conversion. This should produce a single hex file without the manual header-stripping and byte-patching.
For the hard-coded flag, see if it can be placed as a proper linker section (with an ALIGN directive) in one of the two source projects, so it merges in cleanly via --load_image rather than being patched into the hex text afterward.

References:

[FAQ] FAQ on Flash software for C2000 MCUs (Q11: combining multiple executables into one file) https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1464964/faq-faq-on-flash-software-for-c2000-mcus

TMS320F28069F: How to generate one .hex file for two separate projects: boot and application code? : https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1346257/tms320f28069f-how-to-generate-one-hex-file-for-two-separate-projects-boot-and-application-code

CCS/TMS320F28335: Combine bootloader and application into a single HEX file — https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/685825/ccs-tms320f28335-combine-bootloader-and-application-into-a-single-hex-file

TMS320F28P65x TRM (SPRUIZ1B) : Sections 12.6.3, 12.7, 12.9 (alignment/ECC constraints referenced above): https://www.ti.com/lit/ug/spruiz1b/spruiz1b.pdf

Regards

Arpit

C2000™︎ microcontrollers

C2000 microcontrollers forum

TMS320F28P650DH: Loading hex with CCS is VERY SLOW