TMS320F28379D: DSLite programs Flash and OTP in wrong order

For more context: https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1393575/tms320f28379d-using-dss-for-automatic-programming-the-chip

Hi Piotr,

I'll be able to get back to you on this by early next week.

Thanks and regards,

Charles

Hi Piotr,

Are you able to share an example map file for the project that was flashed? 

As for DSLite executable, this is not something I have contributions to.

I'll have to discuss internally with my team on the behavior witnessed.

Thanks and regards,

Charles

Hi Charles,

here is the map for hex file:

********************************************************************************
TMS320C2000 Hex Converter                                                v22.6.0
********************************************************************************

INPUT FILE NAME: <Bootloader_cpu01.out>
OUTPUT FORMAT:   Intel

PHYSICAL MEMORY PARAMETERS
   Default data width   :  16
   Default memory width :  16
   Default output width :  16


OUTPUT TRANSLATION MAP
--------------------------------------------------------------------------------
00000000..ffffffff  Page=0  Memory Width=16  ROM Width=16
--------------------------------------------------------------------------------
   OUTPUT FILES: Bootloader_cpu01.hex [b0..b15]

   CONTENTS: 00078028..0007802f   Bootloader_cpu01.out(dcsm_zsel_z1) Data Width=2   
             00078228..0007822f   Bootloader_cpu01.out(dcsm_zsel_z2) Data Width=2   
             00080000..00080001   Bootloader_cpu01.out(codestart) Data Width=2   
             00080002..0008013d   Bootloader_cpu01.out(.text_a) Data Width=2   
             0008013e..00081fff   Bootloader_cpu01.out(.text.1) Data Width=2   
             00082000..000826ff   Bootloader_cpu01.out(.text.2) Data Width=2   
             00082700..00083964   Bootloader_cpu01.out(.text_c) Data Width=2   
             00084000..00084733   Bootloader_cpu01.out(.econst) Data Width=2   
             00084734..00084d49   Bootloader_cpu01.out(.TI.ramfunc) Data Width=2   
             00084d4a..00084d99   Bootloader_cpu01.out(.cinit) Data Width=2   
             00084d9a..00084da1   Bootloader_cpu01.out(.pinit) Data Width=2   
             00084da4..00084dad   Bootloader_cpu01.out(.binit) Data Width=2   
             00085f40..00085f6f   Bootloader_cpu01.out(.textapi) Data Width=2   

--------------------------------------------------------------------------------
00000000..ffffffff  Page=1  Memory Width=16  ROM Width=16  "*DEFAULT PAGE 1*"
--------------------------------------------------------------------------------
   NO CONTENTS

I only pass hex file to programing software. It always starts from programing OTP.

Regards,

Piotr Romaniuk

Ok, thanks Piotr. I'll need some to go over this file and the flow, will give you an update by Monday.

Thanks and regards,

Charles

I'll need to check into the DSLite options for programming to see if flash OTP programming can be bypassed.

Thanks and regards,

Charles

Piotr,

The programming order for DSLite is determined by the compiler used. In using the hex2000 utility, the write order is determined by the order the memory is specified in the file. If multiple files are being loaded, the memory is loaded in chunks. 

Thanks,

Charles

Hi Charles,

that is not true.
From my tests I concluded DSLite sorts data in ascending address order. That is in one hex file and multiple files in one execution of DSLite as well.

I performed two tests:

1. I prepared hex file where OTP sectors where after Flash,

2. I split OTP and Flash into two hex files and provided in command line to DSLite.

In both cases OTP were programmed as the first.

Regards,

Piotr Romaniuk

Hi Piotr,

Let me connect with you the expert on this matter. Thanks for your patience.

Best Regards,

Aishwarya

Piotr Romaniuk said:

From my tests I concluded DSLite sorts data in ascending address order.

I am seeing this behavior also. I have a single hex file and regardless of how I order the contents, it is always flashing in ascending address order. We are investigating.

Hi Ki,

can you send me exact command line for DSLite and an example of .hex file where OTP will programmed before FLASH?

Regards,

Piotr Romaniuk

Piotr Romaniuk said:

can you send me exact command line for DSLite and an example of .hex file where OTP will programmed before FLASH?

To be clear, you will have to run dslite twice - one for each hex file.

So run dslite for just the OTP hex file first.

Then run dslite again for the non-OTP hex file.

This is the only way to ensure the OTP hex file is flashed first.

Hi Ki

this is not the solution. Each start of DSLite is time consuming. 

Why there is an assumption that programing must be in ascending addresses order? This is a strong limitation of usage.

For this cpu prorgamming OTP before FLASH can lead to locked cpu with incorrectly programmed flash. Restoring it is non-trivial.

How deep is this rule required (DSLite, debug server...)?

At least DSLite should keep specified order of different segments (that would distinguish OTP and FLASH) in hex file or should keep the order specified in comma separated DSLite argument list.

Regards,

Piotr Romaniuk

Hi Piotr,

We looked at this some more. 

Please try this workaround:

• load as a single file,
• set FlashAlignCombineToggle to true, and
• set FlashAlignmentSize to 0 (not an empty string)

This should disable the alignment feature and thus re-ordering. But now you're responsible to ensure the segments are aligned properly as required by the flash loader and the hardware.

Thanks,

Oliver

Hi Oliver,

Thank you for suggestion. 
In my opinion aligment and re-ordering should be separated features controlled by two options.

Can you explain what does it mean "proper alignment for the flash loader and hardware"?

Regards,
Piotr Romaniuk

Piotr,

The TMS320F28379D has Error Correction Code (ECC) Protection feature, which is calculated on per 64-bit memory range in flash memory. To make sure that another program data doesn't write to the same 64-bit memory range that has already been programmed (and therefore the ECC 8-bit data would have been calculated and written), we order the program data, make the calculation, and program the data.

By turning off the ordering like Oliver suggested, you have to manually make sure that the data in your program is 64-bit aligned, otherwise, you might run into a program load error.

As for the current ordering algorithm we are using, yes it is not the most optimal. It would be nice if the Program Loader recognizes that it should prioritize writing to Flash memory first before OTP (or RAM). But unfortunately, we don't have that information at that component level right now, which is why it just does an order by ascending address.

Thanks.

Hi Ricky,

thank you for explanation. 
Between the compiler and the programmer that is data .hex format.
Can you define the rule that I must satisfy on this format level?

Regards,
Piotr Romaniuk

Piotr,

From the program loader, the 2 settings that Oliver mentioned are the related ones that control alignment and performance.

As for the compiler, I'm not aware of any settings for preventing programs from writing to the same 64-bit memory; but I can try asking around to see if there is such options.

In general, if you are able to load your program and you don't see any errors, then there are no alignment issues.

Thanks,

Ricky

Hi Ricky,

Ricky Lau said:

As for the compiler, I'm not aware of any settings for preventing programs from writing to the same 64-bit memory

I think it is wrong statement. It is very common that variables or program are in the same 64bits block. The first question is how should look input hex file for DSLite to be considered as properly ordered and aligned. I suspect that two rules must be satisfied:

1) ascending order of addresses

2) some king of alignment of data chunks in the input hex file.

It probably means that it is forbidden to spread data from single 64 bits block into two lines of intel hex file.

The answer may be in the code that performs alignment and ordering. It has a file in intel hex format as an input and produces data structure in required form.

If you can describe this transformation I will be grateful.

Ricky Lau said:

In general, if you are able to load your program and you don't see any errors, then there are no alignment issues.

This rule is not acceptable in mass production, because it relies on error detection of input data. 
There are two cases:

a) the error may be not detected, resulting incorrect flash contents,

b) even if error detection is perfect and [a] never happens, after some changes in source code new compilation may generate incorrect data. It will be detected but would block production.

The proper manner is to provide input data in correct form. That why I am so persistent in searching the answer.

There probably is a backlog of new features and issues to be fixed for DSLite and DSS. Maybe ordering control and pipe support should be added to it [?].

I see some quality dissonance between TI electronics and the manufacturing software. The electronics (as well as development  software) is high grade proper for critical aplications while production software looks like it is still in early stage. 

Regards,
Piotr Romaniuk