TMS320F28377S: Firmware Update Flash Write Observation - error 509 for empty hex file address , Continuous 0x0000 not writing for empty hex file address

Yogesh, 

For your bootloader, are you using the Flash kernels provided in C2000Ware? Are your applications aligned to 128 bit boundaries? If this is not the case, writes to Flash may not occur as expected. 

I will ask the hex utility expert about your second question and get back to you. 

Thanks, 

Anu

Thanks Anu for reply.

Bootloader which i mentioned in my query is the separate code which reside in Sector A. After execution of bootloader code, it jumps to start address of K sector where Main application reside.

Our flash write operations are 128 bit aligned.

Our Hex file has non - empty address space from 0xB8000 to 0xBD7A8 (Sector K,L,M). Hex file has empty address space from 0xBD7A8 to 0xBDFFA(Sector M). During firmware update, controller used to received hex file data with address for K,L,M sector. controller used to compute address for sector B, C, D by offsetting 0x36000 and write it into flash. 

As mentioned in our query, all write operation works correctly for non-empty address space. For 8 word write at address 0x87EA8 (which is 0xBDEA8 in hex file and belongs to empty address space) we came across 509 error. 0x87EA8 mod 8 = 0, so it is 128 bit aligned address. We can write 8 word at this address.

We observed same behavior multiple times on TMS320F28377S and TMS320F28379D.

Also as i mentioned in my query, While writing hex file to B,C,D sector, for hex file address 0xBD966 and above which is for empty address space, the 0x000 data not get write to memory and it remain to 0xFFFF. We observed same in Memory window. API did not gave any error. For empty address space 0xBD7A8 to 0xBD966, 0x0000 word write works correctly.

So it looks like writing continuous 0x0000 to flash is the route cause for above mentioned observation. 

Please give your opinion on same and possible ways to handle the observation.

Regards....

Yogesh

Yogesh, 

I will review your questions with a teammate and get back to you by next week. 

A couple of questions - is there an Enum value associated with the 509 error you are getting? Can you share the Flash API function being used when getting this error? 

What is the command you are using with the hex utility? Can you share it?

Thanks, 

Anu

Thanks Anu,

Enum associated with 509 is Fapi_Error_AsyncIncorrectDataBufferLength.

We are using 'Fapi_issueProgrammingCommand' in Fapi_DataOnly mode

For generating hex file we are using hex.cmd file with following configuration

-image
--memwidth 16

ROMS
{
FW_IMAGE:
origin = 0x0B8000, length = 0x00584D, romwidth = 16
files = {fwImage.hex}
}

As mentioned above we are we are adjusting 'length' to avoid empty address space in hex file. Looking for easy option to overcome empty address space from hex file

Regards...

Yogesh

Thanks Yogesh, will get back to you by next week.

Yogesh,

Want to add couple of comments.

Fapi_Error_AsyncIncorrectDataBufferLength occurs when "the given start address + the given length" for the program command goes out of the 128-bit aligned segment.  Meaning, start-address+length is not in the same 128-bit segment that has the start-address.  Please check the length that you are passing for the instance when you got this error from the flash API.

API does not do any special thing to block program for the address 0xBD966 and above.  You can send us a specific test case to reproduce it.  From our side, we don't see any issue.  Please check for the start address and the length here as well.

I will let Anu continue this discussion further with you.

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks input from your side.

We are working on creating test case which we can share with you. Also we will will repeat the problem which we are facing multiple times to understand exact pattern or root cause of issue.

Regards....

Yogesh

YogeshG said:

we are we are adjusting 'length' to avoid empty address space in hex file. Looking for easy option to overcome empty address space from hex file

I want to understand what corresponds to this empty space.  So that I can do that, please submit the linker map file.  It usually has the same name as the CCS project, but with the file extension .map.  Please put it in a zip file.  Then attach that zip file to your next post.

Thanks and regards,

-George

Hi George 

Thanks for your reply. 

Sorry for late reply from my side.

As we mentioned earlier we are using  hex.cmd utility as below  to generate hex file.

--image
--memwidth 16

ROMS
{
FW_IMAGE:
origin = 0x0B8000, length = 0x006000, romwidth = 16
files = {fwImage.hex}
}

Linker file we configured to generate code for K,L, M sector.

So to hex.cmd utility we are passing start address of K sector and length of K, L , M together as 0x6000.

The generated hex files used to pad 0x00 for non space address region.

To avoid 0x00 padding we used to adjust length = 0x006000.

We are looking for option to generate hex file without 0x00 padding  without changing the length filed in hex.cmd utility or using some other option.

Still you need map file, then please let me know. I will share same with you tomorrow

Thanks....

Yogesh.

Yes, I still need the map file.  Thanks!

-George

Hi George,

Find below map file for your reference.

Machine_F28377S.zip

Please suggest us possible solution,

• To avoid padding of 0x00 data at the end of hex file
• To pad 0xff instead 0x00 data at the end of hex file

We are still facing the issue as we mentioned at the start of this post. The issue in short as below.

• Hex file has non zero data for active address and  zero padded data for non active address which is at the end of hex file
• As a part of Firmware update, receiving each line of hex file over serial and writing same in reserve sector.
• writing data for active address is working correctly
• Writing data (0x00) for non active address result flash content remain 0xFF without any flash api error. After few write, Flash API return invalid length error.

We tried to simulate the error using attached function where we are writing  

• non zero data for active address
• zero data for non active address

void TestWrtiteToFlash(void)
{
	Uint32 lflashWriteAddress;
    for (lflashWriteAddress = 0xB8000;lflashWriteAddress <= 0xBD7A8;)
    {
    noOfWordsToWrite=15;
    flashWriteAddress = lflashWriteAddress;
    flashWRDataBuf[0]=0x1;
    flashWRDataBuf[1]=0x10;
    flashWRDataBuf[2]=0x25;
    flashWRDataBuf[3]=0x1234;
    flashWRDataBuf[4]=0x9876;
    flashWRDataBuf[5]=0x1010;
    flashWRDataBuf[6]=0x9876;
    flashWRDataBuf[7]=0x1010;
    flashWRDataBuf[8]=0x1;
    flashWRDataBuf[9]=0x10;
    flashWRDataBuf[10]=0x25;
    flashWRDataBuf[11]=0x1234;
    flashWRDataBuf[12]=0x9876;
    flashWRDataBuf[13]=0x1010;
    flashWRDataBuf[14]=0x9876;
    flashWRDataBuf[15]=0x1010;
    WriteToFlash();
    lflashWriteAddress= lflashWriteAddress + 15;
     }
 
    for (lflashWriteAddress = 0xBD7B7;lflashWriteAddress <= 0xBDFF0;)
    {
    noOfWordsToWrite=15;
    flashWriteAddress = lflashWriteAddress;
    flashWRDataBuf[0]=0;
    flashWRDataBuf[1]=0;
    flashWRDataBuf[2]=0;
    flashWRDataBuf[3]=0;
    flashWRDataBuf[4]=0;
    flashWRDataBuf[5]=0;
    flashWRDataBuf[6]=0;
    flashWRDataBuf[7]=0;
    flashWRDataBuf[8]=0;
    flashWRDataBuf[9]=0;
    flashWRDataBuf[10]=0;
    flashWRDataBuf[11]=0;
    flashWRDataBuf[12]=0;
    flashWRDataBuf[13]=0;
    flashWRDataBuf[14]=0;
    flashWRDataBuf[15]=0;
    WriteToFlash();
    lflashWriteAddress= lflashWriteAddress + 15;
     }
	 
}

This function working correctly and not giving error as we mentioned above.

Our application code update following parameter in function basis the command received over serial. That the only difference.

noOfWordsToWrite
 lflashWriteAddress;
flashWRDataBuf

So why it is failing for "zero data for non active address" , we are still working on same.

Please suggest us, Possible reason for the error and possible way to diagnose the issue.

Thanks....

Yogesh

Hi George,

Thanks for the reply. It solves our requirement for generating hex file with 0xFFFF padding and without padding.

For flash related query i will reopen new ticket after few experiment from our side.

Regards...

Yogesh