TMS320F28388D: CM blinking LED flash application does not boot from flash after flash_kernel download

Hello,

A small update, I now see that not all data has been stored on the CM flash. Sorry for misleading you, but I did not verify the whole flash memory inside the CM, which is supposed to be programmed.

It seems that data on the CM flash is missing not just by my own 'flash_kernel' application / PC-Tool but also by the TI 'flash_kernel' project / ‘serial_flash_programmer.exe’ tool. For example the data that comes after the 6 bytes at address 0x200000 is not there. See above picture at byte address 0x200006, you will see only 0xFF.

I did some more debugging on my own 'flash_kernel' project, but please note that I copied almost each functions I am using from your TI 'flash_kernel' example. I added a breakpoint at each place where the Flash access fails, basically where the 'fail' variable is incremented. I run into an flash API fault when trying to program the first data on flash address 0x200008:

According to the map file it is the following:

run origin load origin length init length attrs members
---------- ----------- ---------- ----------- ----- -------

1fffe000 00200008 00000172 00000172 r-x
1fffe000 00200008 00000172 00000172 r-x .TI.ramfunc

00200008  RamfuncsLoadStart 

Any idea why the flash API function 'Fapi_issueProgrammingCommand' fails when programming address 0x00200008? The error code in the picture states ''Fapi_Error_AsyncIncorrectDataBufferLength".

Is there an alignment problem (alignment missing inside linker command file)? I took the basic blinking LED example as is and made no modifications inside the linker command file.

Thanks,

Inno

Inno,

Can you share the linker cmd file that you are using? 

In the linker cmd file, you can see that we use ALIGN(8) (on C28x) and ALIGN(16) (on CM) to align the start address of the all the flash mapped sections to 128-bit aligned boundary.  Please check.

I will ask our kernel expert to help you if you have further questions.

Thanks and regards,

Vamsi

Hello Vamsi,

It works now that I added the ALIGN(16) to the CM linker command file for all flash-mapped sections. Thank you for you support!!!

So that means that the 'flash_lernel' example project has a demand for the application to be 128-bit aligned, since otherwise the Flash API causes problems. I can imagine that I am not the only one who missed the ALIGN instructions in the linker command file, since certain example projects such as blinking LEDs come without that ALIGN instruction in the linker command file.

Allow me to make a suggestion for the 'flash_kernel' project, which your colleagues may find interesting (I refer to the CM flash_kernel project):

Let us assume that you are adding the following code...

uint16_t addressAndLengthCompensation;
// Check how much we are away from a 128-bit aligned address
addressAndLengthCompensation = BlockHeader.DestAddr & 0x000000FFL;
// Move destination address artificially to the next lower 128-bit aligned address
BlockHeader.DestAddr -= addressAndLengthCompensation;
// Increase block size by the number of bytes that we moved the address
BlockHeader.BlockSize += addressAndLengthCompensation
// Fill the array with 0xFF, which means let the flash untouched
for(i=0; i<addressAndLengthCompensation;i++)
{
   Buffer[i] = 0xFF; 
}

...at this place where the red arrow points to:

From now on let the following three 'for(j = 0; .....)' loops start from 'addressAndLengthCompensation' like here:
'for(j = addressAndLengthCompensation;...) 

Furthermore clear the variable addressAndLengthCompensation after running for the 1st time at this place, which means that the variable 'addressAndLengthCompensation' has only for one time a value unequal 0:

I did not verify my approach but I am sure you know what I am aiming for. With that kind of alignment correction code you will allow users to forget the ALIGN adjustments inside the application linker command file, which may reduce customer feedback on your side. It would be great if you could ask the flash_kernel experts to think about it, maybe they like the idea.

Thanks,

Inno

Hi Inno,

Glad it worked for you.  And, thank you for the feedback - I will forward that to our kernel developer.

Flash API does not cause the problem - It catches the problem when someone (here kernel) instructs it to program with no alignment.  Flash wrapper in the device does not allow program across two 128-bit segments at the same time.  Hence, flash API issues that error as explained in the flash API guide.

Regarding the code suggestion/feedback:  There can be scenarios where users do not want to program the unspecified addresses with 0xFFFF along with ECC since they may plan to program those locations at run time.  If ECC is programmed for 0xFFFF data, users will not be able to program their data again in those locations without an erase.  Also, we saw scenarios where there can be more than one image and they may share the 128-bit segment (lower 64-bit and upper 64-bit).  To avoid programming issues in all such situations, we said we always suggest the users to align the sections in the linker cmd file on a 128-bit boundary.  

Could you please provide me the path for the linker cmd files that are not using ALIGN()?  I will file ticket to fix those linker cmd files. Thank you.

Thanks and regards,
Vamsi

Hello Vamsi,

I think I understand why my approach (to artificially move the flash address to a 128-bit aligned address) is not OK, it will/may cause ECC problems.

About the linker command file that has no ALIGN() instruction:

I have to admit that I had to work with a C2000 ware version 03.04.00.00 package, since our product is currently compiled based on that version. Therefore I imported the blinking LED example from that file path.

C:\ti\c2000\C2000Ware_3_04_00_00\driverlib\f2838x\examples\c28x_cm\led

It may be that the ALIGN() instructions have already been added to the C2000 Ware version 04.00.00.00 linker commands, but I for sure they were missing in the previous version.

Unfortunately I could not make the test for you, importing the blinking LED example from this folder:

C:\ti\c2000\C2000Ware_4_00_00_00\driverlib\f2838x\examples\c28x_cm\led

For some reason I received an import error message:

Although I believe the compiler is installed:

Thanks,

Inno

inno said:

Unfortunately I could not make the test for you, importing the blinking LED example from this folder:

C:\ti\c2000\C2000Ware_4_00_00_00\driverlib\f2838x\examples\c28x_cm\led

For some reason I received an import error message:

See CCS 11 cant import project for a possible reason, and work-around. Basically, some example project are set to reference a non-existent ARM compiler version for the Cortex-M CM CPU.

Inno,

You can try the suggestion from Gillon on importing the project.  If you need further help on project import, please open a new post - we will assign it to corresponding team.  I am closing this post since the original question is answered.

Thanks and regards,

Vamsi

Hi Vamsi,

I did what was proposed in that link, I deleted the following line from the file 'empty_c28x_cm_driverlib_project.projectspec' inside folder 'C:\ti\c2000\C2000Ware_4_00_00_00\driverlib\f2838x\examples\c28x_cm\empty_projects\CCS':

cgtVersion="21.6.0.LTS"

But it did not work, I still could not import the LED example due to the same error message. Maybe it is because I am using a CCS 10.4 version. But nevermind, I can also import that blinking LED project from the C2000 Ware 03.40.00.00 version, This works fine. So I am not blocked anymore and you can close this particular bug report.

Thanks,

Inno 

Hi Inno,

Apologies for the delayed response.

You can update the compiler version of the CM side project to 20.2.5.LTS

name="empty_c28x_cm_driverlib_project_cm"
device="Cortex M.TMS320F28388D"
cgtVersion="20.2.5.LTS"

This issue will be fixed in the upcoming C2000ware release.

Regards,

Veena