TMS320F28388D: issue about the firmware upgrade file transfer data format

Yale,

I'm trying to find the right SME to help with your question.

Thanks,

Sira

Hi Yale,

Please ask customer to clarify below questions so that we can analyze this better and loop in the appropriate expert to help them:

Customer mentioned that they referred to SCI serial port firmware upgrade solution from TI.  As the customer might have noticed, the ROM SCI bootloader requires the host to send the target destination address, data length and the data in a specific order - which is explained in the TRM's section 5.8.1.1 Bootloader data stream structure.  This specific structure uses the ASCII-HEX object format for the address and data bytes - which is nothing but "four address bytes followed by data bytes".  All the other info like the key value, reserved words, block length etc. also should be part of this structure in bytes as explained in the above mentioned TRM section.  Users can use the Hex2000 utility to generate this specific Bootloader data stream structure format file (file.txt) from the object file (file.out) using below command mentioned in the Serial Flash programming application note (http://www.ti.com/lit/pdf/sprabv4)

The SCI host programmer parses the output of the Hex2000 utility (file.txt) and sends the information in bytes to the ROM SCI bootloader on the target device.  

Question: Customer said "When programming the Flash sector, I found that the ANSI encoding format was programmed, but the ASCII encoding format was actually programmed through the programmer".

1) What is the programmer that the customer used when they said  "When programming the Flash sector".  Is it their custom Ethernet-based firmware update solution?

2) How did the customer confirm that the ANSI encoding format was programmed?  Can they provide more details on what they mean by ANSI encoding format?  Can they provide some debugger memory window snapshots and explain clearly?

3) When customer said "ASCII encoding format was actually programmed through the programmer", what is the programmer they are referring to?  Are they referring to TI's CCS On-chip flash plugin Or Uniflash Or Serial SCI flash kernel Or some other 3rd party solution?  Please provide more details on what they mean by ASCII encoding format here.  Can they provide some debugger memory window snapshots and explain what they mean?

4) In their custom flash programming solution, what exact data did they provide to the flash API's program command and what did API program in to the flash memory?  Can they provide some memory window snapshots for our understanding?

5) As per my knowledge, there is no Ethernet bootloader on this device (I am not Ethernet or F28388x ROM expert - I maybe wrong. I can confirm with the BootROM team in a day or two).  What exact command is the customer using with the Hex2000 utility for use with Ethernet module?

Thanks and regards,

Vamsi

Hi Vamsi,

Thanks for your reply.

The customer is using an Ethernet-based firmware upgrade solution. They use CCS to generate an upgrade file in intel hex format, and send the upgrade file to the C2000 through the TFTP protocol for upgrade.

At first, they used the host computer to directly send the hex file to the C2000. They found that the C2000 received the data in the red box in the picture below, so the program could not be used normally.

Later they discovered that they needed to convert the hex file to the data on the right part before sending it to the C2000. Because they found that the routine did not have this conversion process, they thought that using the sci solution to upgrade would directly send the hex file to the C2000.

+++++++++++++++++++++++++++++++

Another issue is that they used CCS to generate Intel hex files. After checking the data, they found that there is data outside the Flash address, but these data cannot be programmed through FlashAPI. How should these data be programmed?

The red box represents the data at address 0x00001500

The data outside the red box represents the data after Flash address 0x00080000

Similarly, there is a similar situation in CM:

Hi Yale,

All of the flash tools (TI or 3rd party) are developed for fully embedded applications.  Meaning, all of the initialized sections in the linker command file should be mapped to flash.  If there any functions (code) that needs to be copied to RAM for execution (for performance or IP initialization reasons), then that code should be copied to RAM at run time before calling those functions.

Thanks and regards,

Vamsi

Hi Vamsi,

Do the data outside the flash address in the generated intel hex file represent data that needs to be copied to RAM? Do we need to ignore this part of the data when programming the hex file?

--

Thanks & Regards

Hi Yale,

Did customer map any initialized sections to RAM address range in the linker command file?

Thanks and regards,

Vamsi

Hi Vamsi,

This is the customer's linker command file. Please take a look.

2838x_FLASH_CLA_lnk_cpu1_1.zip

--

Thanks & Regards

Hi Yale,

I will review and get back to you tomorrow.

Thanks and regards,
Vamsi