TMS320F280049C: DSP280049 Live DFU TI example query

Hi Xu,

F28004x has 2 Flash banks so you should be able to have the kernel stored in both Flash banks, and each bank's Flash kernel can run and erase/program the other bank's application.

I am not sure which document or where it says "Kernel should run in RAM". If you can send me details (doc, section number, etc.) I can clarify.

Thanks,

Sira

Hi Sira,

Thanks for your reply.

I know the method you mentioned about F28004x Fw upgrade is Live DFU,so it will need stored two kernel in blank0 and blank1 respectively, but as I know Flash API should run in RAM then it can work successfully erase and program application, the kernel contains flash API ,so if it stored in flash, can it work normally?becasue I saw in F28004x  kernel demo project the Live DFU code all put in flash by CMD.

Another question is:

  Except Live DFU,if I don't want to use LIve DFU, I mean DFU not use two blakns,

I found in document"Serial Flash Programming of C2000 Microcontrollers" ,it introduce another method is set the demo board to SCI boot ,and send kernel  by PC,the device will receive the kernel first and put them in RAM,so it can erase /program application,as below:

So my question is why in this case Kernel should be in RAM but in Live DFU case Kernel put in flash?

In the 2 Flash bank case e.g. F28004x, the Flash kernel (including Live DFU) as well as the Flash APIs can run from Flash. They don't need to run from RAM. The source file showing Live DFU running from RAM is not necessary in this case.

The above method uses Flash boot, where the entry point is into the Flash kernel.

In the sprabv4 document you refer next, it describes a general firmware update approach (not Live Firmware Update) using SCI boot where the Flash kernel is not already present in Flash, but downloaded to RAM. Hence the Flash kernel + Flash APIs are in RAM in this case. They execute and program the Flash with the application. Then if you perform a device reset and switch to Flash boot, the Application will run directly. The Flash kernel + Flash APIs will no longer be present (in RAM or in Flash).

Hi Sira,

I tried to use SCI boot mode for DFU to study the algorthm about it.

For sure I set up the demo 280049C board for SCI boot mode, and then I use TI demo code"flashapi_ex2_sci_kernel" act as my kernel. and t I also use Ti demo code"flashapi_ex3_live_firmware_updateBANK0FLASH" as my application. Then I can successfully erase and porgram demo appilication into flash.

After that, I tried to use my own application(not Ti project) with Ti kernel(mantioned above), but progarm failed, PC log as below:

I don't know why my applicaion code can't be programmed successfully, can you give me some guidence about this issue?

in map file: 0x889be with FPUmathTables

It seems this error occurs because the Flash address is not aligned, and because it is so, the Flash API reports out a data buffer length error.

The Flash address 889be is aligned to a 16-bit boundary. However, Flash ECC requires it to be aligned to a 64-bit boundary i.e. the address can be 0x88900 or 0x88940 or 0x88980 or 0x889c0.

How is FPUmathTables specified in your linker command file?

Hi Sira,

the FPUmathTables is put in flash memory as below:

And it seems I have a new finding： that is I change the CCS output format from eabi to COFF(as below)，that can fixed my issue. But I don't know the root cause, can you give me some guidance about it?

best&regards

lucas

Can you provide the address of FPUmathTables in the coff output map file?

Hi Sira,

Address of  FPUmathTables in the coff output map file as below:

Hi Sira,

Did you have any comments why I use coff output format  instead of  eabi output format that I can DFU successfully? thanks!

best&regards

lucas

Xu,

On the F28x, every address corresponds to a 16-bit boundary e.g. 0x0, 0x1, 0x2, 0x3, ..since every address points to a 16-bit word

Every alternate address corresponds to a 32-bit boundary e.g. 0x0, 0x2, 0x4 (i.e. Least significant bit = 0)  -> the EABI address for FPUmathTables falls into this category (889be, e = 1110)

If you want alignment to a 64-bit boundary, you need to have addresses like 0x0, 0x4, ..(i.e. 2 least significant bits = 0). -> the COFF address for FPUmathTables falls into this category (890ac, c = 1100)

This is why it works in COFF. It's not because of COFF. It's because of the address change.

Thanks,

Sira

Hi Sira,

 It seems this issue doesn't related to eabi or coff,just depends on the address format,so if I want to continue use eabi, is there any solution let the address of FPUmathTables  to keep alignment to a 64-bit boundary?

best&regards

lucas

Hi Xu,

Yes, in the linker command file you can assign FPUmathTables to a specific sector where nothing else is allocated. Then the compiler will allocate it to the start of that sector, which will definitely be a 64-bit aligned address.

Thanks,

Sira