• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 86 subscribers
  • Views 328 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28384S: The limitation of CM TXT file generation for SCI flash kernel

Luke Chen
Expert 5090 points
Part Number: TMS320F28384S

Hi champs,

We have to use below command and convert .out file into correct hex file(.txt file) for SCI flash kernel.

"${CG_TOOL_HEX}" "${BuildArtifactFileBaseName}.out" -boot -a -gpio8 -o "${BuildArtifactFileBaseName}.txt"

In real application, my customer needs to fill data 0xAA5555AA to flash sector 9 in the application code, he uses below command in linker command file and generates the .txt file. However, he fails to do the firmware upgrade via SCI boot with this hex file.

CMBANK0_SECTOR9   : origin = 0x00260000, length = 0x00010000, fill = 0xAA5555AA

I check the .txt file and find that the data block size is 2-byte in length, so the maximum data length is limited to 0xFFFF and this should be the root cause my customer fails to do SCI firmware upgrade, is it correct?

If this is the case, when customers want to generate CM hex files for SCI flash kernel, should we say the maximum length should be limited to 0xFFF0 since the flash memory is 128-bit aligned?

Regards,

-Luke

  • 0
    TI__Guru 50511 points

    Hi, Luke,

    Yesterday compiler expert reviewed it. We are assigning to subject matter expert. We should expect response later today.

  • 0
    TI__Guru* 87105 points

    Hi Luke,

    What is the error that the customer got when using SCI flash kernel?

    I need to check whether the length restriction is applicable for CM SCI boot loader or not - I will check and get back to you next week.

    Can you try splitting that sector in to two parts in the linker cmd file and see if that helps resolve the issue?

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Expert 5090 points

    Vamsi,

    The SCI upgrade process will stuck due to wrong HEX content.

    I understand this problem can be fixed by splitting the sector into two parts. In real applications, sometimes customers combine several flash sectors into one big sector so that they maintain .cmd file easier, for example customers combine sector1 to sector4 into one big sector1_4. The block data size is two-byte in length, this could be the problem HEX tool generating wrong HEX files for SCI flash kernel, both the HEX tools of C28x and CM.

    This is the first time we face this kind of SCI upgrade problem, please help to check this.

    Thanks for regards,

    Luke

  • 0 in reply to Luke Chen
    TI__Guru* 87105 points

    Luke,

    Is customer filling (fill = 0xAA5555AA) the unused addresses of sector 9 (OR) the entire address range of the sector 9?

    Meaning: Is anything mapped to sector 9 OR Only the fill?  May I know why they are doing the fill?

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Genius 17370 points

    For CM as well the data copy from IPC is limited to 2 bytes.

  • 0 in reply to Vamsi Gudivada
    TI__Expert 5090 points

    Vamsi,

    Let's focus on this sector length problem, not just for flash sector 9.

    Since the data block size is 2 bytes, then customers need to limit the sector length less than 0x10000 to avoid generating incorrect .txt file for SCI flash kernel, both C28x and CM. For example, customers should modify sector length as below, split the length into two smaller parts.

    /* CMBANK0_SECTOR9     : origin = 0x00260000, length = 0x00010000 */ /* length should be less than 0x10000 */
    CMBANK0_SECTOR9_1 : origin = 0x00260000, length = 0x00008000
    CMBANK0_SECTOR9_2 : origin = 0x00268000, length = 0x00008000

    Based on below E2E thread, looks like the maximum length for C28x is 0xFFF8(less than 0xFFFE and 128-bit aligned), is it correct? Then what's the maximum sector length for CM4 generating correct .txt file for SCI firmware upgrade? Is it 0xFFF0(less than 0x10000 and 128-bit aligned)?

    https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/964813

    Regards,

    Luke

  • +1 in reply to Luke Chen
    TI__Guru* 87105 points

    Luke,

    I assigned this to our kernel expert couple of days ago and noticed that this is open.

    Since we are discussing this offline, I am pausing this post here.  We can post the conclusion here.  

    FYI for others that may refer to this post:  As of now, ARM hex tool does not have any known issues in the above discussed context.

    Thanks and regards,

    Vamsi