This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

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

Part Number: TMS320F28377S
Other Parts Discussed in Thread: TMS320F28379D, , C2000WARE

Dear All,

We are implementing firmware update functionality over TMS320F28377S and TMS320F28379D.

Main application linked to K,L,M sector. For firmware update we copied hex file of Main application to HMI and HMI send file over serial to controller. Controller store receive hex data on B,C,D sector and reset controller.

On reset, bootloader code copies hex data from B,C,D sector to K,L,M sector and jump to start address of K sector.

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)

For testing we first execute Main application code in debug mode.

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 written to memory and it remain to 0xFFFF. We observed same in Memory window. API did not gave any error.

While writing 8 word for hex file address 0xBDEA8 which is for empty address space, API return 509 error.

Then we generate hex file without empty address space by changing the length field in hex.cmd file and tried above exercise.

We did not came across any error and firmware update works well with Bootloader code.

We observed this behavior with both mentioned controller.

Our queries:

1) What might be the possible reason for 0x000 data not get written to memory and it remain to 0xFFFF and error 509 for flash write belongs to empty address space.

2) We removed empty address space from hex file using length filed of hex.cmd file. How we can remove empty address space from hex file using compiler or other option.

Regards....

Yogesh

  • 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

  • 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

    TestWrtiteToFlash.c
    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

  • Please understand that my expertise is limited to the hex utility hex2000.  I have no expertise in flash programming or the related issues.  Thus, my comments here are limited to the hex utility.

    You use image mode in the hex utility.  This is indicated by your use of the option --image and the ROMS directive.  Based on my limited understanding of the situation, you should not use image mode.  If you remove --image and the ROMS directive, I think you will get the hex file you need.  

    To understand more about image mode, please search the C28x assembly tools manual for the sub-chapter titled Image Mode and the --fill Option.

    All that said, please understand that I cannot test this suggested solution, and so I cannot be certain it resolves the problem.

    Thanks and regards,

    -George

  • 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