TMS320F28375S: How to flash BIN files using a custom CAN-based bootloader.

Hello,

If you're flashing a raw bin file that only has data to be programmed to the MCU, then you'll have to keep track of a few variables.

1. You will need to determine the area of flash that needs to be programmed and either hardcode this in your bootloader or use some packet protocol to convey this information.

2. You will need to keep track of the address to be programmed as chunks are received/programmed to the MCU.

3. You will need to have some way of communicating to the target that no more data is coming from the host. You can either communicate and track the image size, have a timeout condition, and end of transmission character/packet, etc.

Are you having trouble with any in particular?

Kind regards,

Skyler

hi, 

Thank you for your response. the points that you have suggested are already done in my bootloader while flashing txt file. However, I’m running into a more specific issue regarding non-linear memory mapping.

When I use a TI TXT file, it contains multiple data sections at different flash addresses. For example, one section might start at 0x88000 to 0x88FFF, then there’s a gap (filled with 0xFFFF), and another section might start later at 0x89380, etc.
The TXT file explicitly includes the starting address of each data block, so my bootloader can correctly program each chunk into its proper flash region.

But when I generate a raw BIN file, all those address offsets and gaps are lost — it only contains the continuous data stream, without any information about where each section belongs in flash. So if I try to flash it directly, all the data chunks end up being written back-to-back, corrupting the program layout.

So my question is:
How can I handle this situation when using BIN files?

also is there any other version or BIN file then Raw BIN file?

is there a way to generate a BIN file that still preserves section addresses from the original TXT file?

Is it possible to modify the project’s linker command file or any build settings so that all code/data sections are placed contiguously in flash (i.e., no empty regions between them)?

Any suggestions or best practices for this scenario would be really helpful.

Thanks again for your time and support!
Muzammil

Hi Muzammil,

For some tips on generating a bin file for the entire memory range, please refer to the response from George on this thread.

Kind regards,

Skyler

Hi Skyler,

Thanks for your response and for sharing the reference thread.

I went through the suggested post, but I wasn’t able to clearly understand how it applies to my case.

In my project, the start address is fixed in the linker command file, and that same address is already managed correctly inside my custom CAN-based bootloader.

What I need is to generate a .bin file where the data stays exactly at its correct addresses, just like in the .txt file. I don’t want the holes or unused memory areas to be ignored; they should simply be filled with 0xFFFF.

A contiguous layout is perfectly fine for me as long as all sections remain at their correct offsets and the memory gaps are filled with 0xFFFF. Could you please provide a proper and detailed solution for generating such a .bin file for the TMS320F28375S?

The thread you suggested was a bit confusing to follow, so a clearer explanation or example specific to this case would really help.

regards,
Muzammil

Hi Muzammil,

The reply from George breaks it down into steps. You will need to create a new linker cmd file that specifies an address range with the ROMS directive. This address range is the range that will be read when generating a bin file. Please note that the memory range specified in the ROMS directive needs to be multiplied by 2 because the hex2000 tool treats it as byte-addressable memory despite the C28x being 16-bit addressable. For example, if you want to generate a bin that contains all data from 0x80000 - 0x90000, your ROMS directive would look like this:

ROMS {
   all_mem: o = 0x100000, l = 0x20000, fill = 0xFFFF
}

Then, you will need to add the post-build step as specified:

hex2000 -q -b -image -o binary_file.bin roms_directive_file.txt final_executable_file.out

Using these steps, you will be able to generate a .bin file that directly reflects the contents of flash and keeps all data at the proper offset. Any un-programmed locations will be filled with 0xFFFF.

Kind regards,

Skyler

Hi Skyler,

I have followed the steps you mentioned above, but I am still unable to generate the required .bin file.

Let me explain in detail what I have done so far:

1. I added the roms_directive_file.txt in my project, which contains:

   ROMS
   {
   all_mem: o = 0x110000, l = 0x05FFF6, fill = 0xFFFF
   }

2. In the project settings, I added the post-build step exactly as you suggested, pointing to the hex utility and using the ROMS directive file.

   

Despite doing this, I am still not able to generate the .bin file as expected.

Could there be any additional point I am missing? Is there a specific setting in the C2000 hex utility that I need to enable or configure? Or could there be another factor I am overlooking that prevents the .bin file from being generated?

currently, except what you told, i have not done any other settings.

Skyler Baumer said:

You will need to create a new linker cmd file that specifies an address range with the ROMS directive.

what changes should i do in linker cmd file or what in new linker cmd file?

I would greatly appreciate guidance.

Regards

Muzammil