TMS320F28075: Hex2000 ascii hex with boot table generation rules?

Hi Hang,

To my understanding, the block dividing is related to 1) the --boot_block_size argument when generating the project, and 2) the boot loader source table used (ex. --sci8).  The SCI bootloader expects the blocks to follow the bootloader data stream structure. For example, the SCI bootloader will receive the .txt file in hex boot format and calculate a checksum over the block size, store the block in a buffer and erase a sector of memory, programming it into RAM as needed.

I would assume that the blocks you are seeing divided are made this way due to a given block size argument. If a continuous memory falls outside the expected block size, it may be possible that it splits into two or more blocks to accomodate itself. I'll need some more information on this as seems related to the hex2000 compiler itself.

Thanks and regards,

Charles

Hi Charles,

Here's an example of divided block.

As you can see from the picture, the first block starts with address 0x000B8000, and its length is 0x0B50.

The second block starts with address 0x000B8B50. The memory in the first and second block is continuous since 0x000B8000 + 0x0B50 = 0x000B8B50. This txt is generated using hex2000 and we didn't specified any block length parameter. Would 0x0B50 be the default maximum block length?

Regards,

Hang.

Hi Hang,

The bootloader has a limitation of how long of a block it can handle for serial communication purposes. One way to replicate this behavior is to use .FILL for very large section (say 0xFFFE). Is it possible for customer to limit the section length/size and divide it?

Thanks and regards,

Charles

Hi Charles,

Charles Roberson said:

Is it possible for customer to limit the section length/size and divide it?

Sort of. They can divide the block in txt, since they're making the tool themself.

Charles Roberson said:

The bootloader has a limitation of how long of a block it can handle for serial communication purposes.

Any idea on suggestion on the limitation? If customer is to divide the blocks, they'll need to know where to cut it.

Thanks,

Hang.

Hi Hang,

Are they able to limit the block size by splitting the used section in half? I would attempt this first (ex. RAMGS_01, RAMGS_02. Without knowing their code, I can't for certain say on the limitation assignment. One thing on the .text section, do you know what combination of RAM it is being mapped to? The default F2807x_sci_flash_kernel has it's .text section mapped to RAMGS0, RAMGS1_code or RAMGS4 by default (assigned to PAGE 0). If able you can add more RAM sections to .text.

Thanks,

Charles

Hi Charles,

Sorry I forgot to mention their use case. Customer is planning to integrate this hex to txt conversion tool into their production process （probably to replace C2PROG）, which means this tool needs to handle the programming of many old projects. These projects are already in production.

Charles Roberson said:

Are they able to limit the block size by splitting the used section in half? I would attempt this first (ex. RAMGS_01, RAMGS_02.

So I do get your point of splitting the sections. But if they do it in cmd file, they'll have to modify every old project, which cost lots of time.

That's the reason why they want to split it when hex is converted to txt. For the moment they are splitting the blocks in a way that imitates the hex2000, and successfully have their app programmed to the product. But they still don't know the reason behind, so that's why they are asking how these blocks are divided.

Regards,

Hang.

Hi George,

That's very helpful, thanks for the information!

Regards,

Hang.