• State
  • Locked Locked
  • Replies 13 replies
  • Subscribers 85 subscribers
  • Views 714 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.

TMS320F28388D: An issue regarding generating a firmware using ARM Hex Utility

Alex Forbes
Intellectual 275 points
Part Number: TMS320F28388D

Hi,

I am using the controlCARD board (TMDCNCD28388D). I am trying to generate the hex format of my firmware using ARM Hex Utility. Then, I load the generated hex file on the flash memory of the CM core by using another firmware developed by myself. However, after loading the firmware and restarting the core, the new firmware will not successfully run. To figure it out, I compared the hex file content with the actual firmware which is generated by JTAG and loaded on the flash. I found out that almost all of both contents are the same except for some specific locations. So, I tried to make changes to the firmware generated by Hex Utility and make it similar to the firmware generated by the JTAG. In this way, after loading the firmware on the flash, the firmware was successfully executed and everything was ok. However, I could find out what was the exact root cause of this problem. But, I found two differences in these two files that might facilitate finding a solution. So, here I present the details of these two differences. I would appreciate it if someone can help me to figure out a solution for this issue.

1- There exist 6 additional bytes at the end of blocks that have the size of 0XFFFF in the firmware generated by Hex Utility while these 6 bytes do not exist in the same blocks in the firmware generated by the JTAG. In the following picture, I have highlighted the additional 6 bytes generated by the Hex Utility. This picture is a snapshot of the end of a block that has the size of 0xFFFF.

Also, I have shown the memory map of the CM in the picture below where the same block of the firmware, which is generated by the JTAG, is loaded. This picture is a snapshot of the end of the same block that I showed in the picture above.

2- The last byte in the firmware generated by the JTAG is "1F" while the last byte (I mean the last byte before those additional 6 bytes) in the firmware generated by the Hex Utility is "00".

Honestly, I do not know what these ending bytes mean. So, I just tried to find a solution. So, I tried to change the firmware generated by the Hex Utility and make it the same as the firmware generated by the JTAG.

Also, as another observation, I should mention that when I try to generate a small size firmware which for example has a size of less than a SECTOR of the flash memory, everything is ok. For example, when I generate a LED_blinky example with Hex Utility, the generated file is the same as the one generated by JTAG. However, when I try to generate a large size firmware, in my case ~170KB, which will be placed on more than one SECTORs of the flash memory, this problem will happen. I would appreciate it if someone can explain why this is happening.

Kind Regards,
Alex

  • 0
    Intellectual 275 points

    Hi,

    I am also attaching the configuration that I used to generate the firmware (by using the Hex Utility). I thought it might be helpful. However, please keep in mind that this configuration worked well for small-size firmwares like LED_blinky.

    Best,

    Alex

  • 0 in reply to Alex Forbes
    TI__Guru**** 244440 points

    I do not completely follow your explanation.  However, it may the case that you have the problem described in this forum thread.  Please let me know if you think your situation is the same.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 275 points

    Hi George,

    Thank you for your reply. I looked at the forum thread that you sent. I believe that is not my case. Because I am able to write the whole firmware (generated by the ARM Hex Utility) with Flash API. This shows that I do not have the alignment problem as has been mentioned in this thread.

    George Mock said:
    I do not completely follow your explanation.

    Let me explain in this way. I have a CCS project and I generate a hex file by using the ARM Hex Utility. Then, I successfully load this generated hex file on the flash memory of the CM core by using Flash API. However, after loading the firmware, when I restart the CM core, the firmware will not successfully run. But, as I mentioned earlier, when I compile my project in CCS and load it on the flash by using JTAG, it successfully works.

    So, after going through the hex file generated by the ARM Hex Utility, I found there are some differences between the content of the hex file (generated by the ARM Hex Utility) and the firmware that is loaded by the JTAG. I explained these differences in my first post. I hope I could clearly explain my issue.

    Best,

    Alex

  • 0 in reply to Alex Forbes
    TI__Guru** 113755 points

    Alex,

    We'll get back to you soon on this.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 275 points

    Hi Vivek,

    Sure. Thanks for letting me know. I will be waiting for you.

    Best,

    Alex

  • 0
    TI__Guru**** 244440 points
    Alex Forbes said:
    when I generate a LED_blinky example with Hex Utility, the generated file is the same as the one generated by JTAG. However, when I try to generate a large size firmware, in my case ~170KB, which will be placed on more than one SECTORs of the flash memory, this problem will happen.

    In the large size firmware, are there any sections larger than 0xfffe words?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 275 points

    Yes, there are two sections with the size 0xFFFF. They are loaded at 0x00210000 (beginning of SECTOR4) and 0x00220000 (beginning of SECTOR5).

    Best,

    Alex

  • 0 in reply to Alex Forbes
    TI__Guru**** 244440 points

    Then it is very likely you are affected by EXT_EP-10175.  Please upgrade to C2000 code generation tools version 22.6.0.LTS, and use the new hex utility option --boot_align_sect.  I cannot guarantee this will resolve the problem.  But I think it is very likely.

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    TI__Guru**** 244440 points

    Oops!  You use a C28x device, but I overlooked the fact you are building for the ARM CPU core on that device.  Please ignore my last post.

    It remains likely you are affected by EXT_EP-10175. However, no version of the ARM code generation tools has implemented the fix.  Is there some way you can, just as an experiment, reduce the size of the large sections to less than 0xfffe?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 275 points

    Thanks for your reply, George.

    George Mock said:

    Is there some way you can, just as an experiment, reduce the size of the large sections to less than 0xfffe?

    By "the large sections", do you mean the sectors of the flash memory in the .cmd file? If so, yes I reduced the size of these sectors in the .cmd file to a random value, for example, 0xFF00 as you can see in the following picture:

    Although this worked well for these sectors, when I change the firmware to somewhere else in the flash memory, it does not work. For example, when I change the location of the firmware from SECTOR7-SECTOR9 to SECTOR3-SECTOR5 it does not work. The highlighted lines in the picture below are the changes that I just mentioned.

    By "the large sections", if you mean something else, please explain to me what exactly should I change?

    Best,

    Alex

  • 0 in reply to George Mock
    Intellectual 275 points
    George Mock said:
    It remains likely you are affected by EXT_EP-10175.

    I also took a look at this link. I think this is like the forum thread that you mentioned before and I believe that is not my case. Because, if the "section alignment" was my problem, I would not be able to write the firmware on the flash and I should receive an error from the Flash API functions. While I can fully and successfully the whole firmware on the flash. But, my problem actually is that after successfully loading the firmware on the flash and restarting the CM core, the firmware cannot successfully run. Am I right, or am I missing something?

    I would appreciate it if you can explain how this link is related to my issue.

    Best,

    Alex

  • 0 in reply to Alex Forbes
    TI__Guru**** 244440 points
    Alex Forbes said:
    my problem actually is that after successfully loading the firmware on the flash and restarting the CM core, the firmware cannot successfully run

    It may appear that the firmware successfully loaded on the flash.  But, because it doesn't run, did it really?

    I notice you you use the armhex option --boot.  I presume this means you use the bootloader, and you require armhex to lay out the code and data in the format expected by the bootloader.  EXT_EP-10175 is about a problem in armhex related to this very use case.  

    When you load the program with CCS (through the menu command Run | Load | Load Program, or something similar), the bootloader is not used.  It is a very different way of getting the program on to the system.  

    Thanks and regards,

    -George

  • 0 in reply to Alex Forbes
    TI__Guru**** 244440 points
    Alex Forbes said:
    By "the large sections", do you mean the sectors of the flash memory in the .cmd file?

    No.  I'll define terms more carefully.  Please read the first part of the article Linker Command File Primer.  Focus on understanding the terms input section, output section, and memory range.  In all my previous posts, when I used the term section, I meant an output section.  

    So, are there any output sections larger than 0xfffe?  If so, as an experiment, remove some of their contents to make them smaller.  See if that one change fixes things.  This experiment may not be practical.  But if it is, it is an easy way to see if my guess is correct.

    Thanks and regards,

    -George