• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 82 subscribers
  • Views 1404 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

F28377S customized bootloader

Jordan Zhou
Genius 10470 points

Other Parts Discussed in Thread: CONTROLSUITE

Hi, 

Customer is using F28377S for their application. Now they are doing their personal bootloader. 

The details are:

1) The bootloader will be loaded at Flash 0x80000, user application will be loaded at 0x88000 through bootloader;

2) Bootloader and their application are two different projects, with their own coststartbranch;

3) Now the bootloader can erase/program/verify Flash successfully; user applications works well if it is loaded separately;

4) The boot logic is simple as, bootloader get the command and then erase/program/verify Flash. Everything is OK here. 

5) Issue happened at asm ("LB #0x88000") in bootloader code. After user code programmed, reset is initiated by WD. Bootloader main() is executed again. As user code already programmed, so there's asm ("LB #0x88000") to switch to user application. It failed to switch there. In debug mode, C28 went to NMI. 

Some other tests are tried, without any improvement: 1) clean RAM; 2) separate the RAM for bootloader and user application. 

Some other info:

1) The user application code in Flash was check, they were totally the same in bootloader erase/program/verify and JTAG erase/program/verify. 

2) In bootloader, switch to bootloader itself like asm ("LB #0x80000"), it was successful. 

3) Codestartbranch was check, no issue founded. 

4) They are also using the same logic in F28377D and F28335, it can successfully switch to user application by asm ("LB #0x88000").

Where can be the issue? Is there some points missed?

Thanks a lot.

Br, Jordan

  • 0
    TI__Guru* 87155 points
    Jordan,

    Did the customer program ECC for the Flash contents?

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 10470 points
    Vamsi,
    There's no ECC and others.
    Two ways to program user application code, one is their bootloader, while the other is JTAG. The Flash data starts from 0x88000 are totally the same. In JTAG mode, user application works well. But in bootloader mode, it doesn't work.
    Thanks a lot.
    Br, Jordan
  • 0 in reply to Jordan Zhou
    TI__Guru* 87155 points
    Jordan,

    What is the tool that the customer used to program Flash via JTAG? The tool might be programming ECC and hence they did not notice any issue.

    When they program the Flash via their bootloader, they should be using the Flash API. I think the customer is not programming the ECC when programming the Flash using API. F28377S Flash has ECC (unlike F28335) and ECC must be programmed. If not, ECC errors will occur leading to NMI.

    Ask them to use Fapi_AutoEccGeneration mode (instead of Fapi_DataOnly mode) when programming the Flash with API.

    Thanks and regards,
    Vamsi
  • 0 in reply to Vamsi Gudivada
    TI__Genius 10470 points
    Vamsi,
    After adding the ECC, now jump LB can work, but soon NMI happened again. We checked the data in Flash ECC location, there are some extra data in ECC. We don't know why they were written. Is there any Flash command to stop the ECC auto generation? Hope there's a detailed doc for Flash API.
    Thanks a lot.
    Br, Jordan
  • 0 in reply to Jordan Zhou
    TI__Guru* 87155 points

    Jordan,

    Good to know that the debug progressed.  

    Did you check the NMIFLG register to know the source of NMI?  Since Flash ECC got programmed by the customer, NMI may not be because of the Flash ECC error.

    Programming ECC does not cause an NMI.  ECC must be programmed to avoid ECC errors (NMI).  Since the customer programmed using Fapi_AutoEccGeneration mode, ECC gets programmed and that's what you noticed in the ECC space.  ECC is explained in section 2.12.10 Error Correction Code (ECC) Protection in the TRM at http://www.ti.com/lit/ug/spruhx5c/spruhx5c.pdf.  Please refer to this section for ECC details.  If you need details on the Flash API, refer to documents at C:\ti\controlSUITE\device_support\F2837xS\vx\doc\FlashAPI_Doc.  Hope you have the latest Controlsuite.

    Also, check out the FLASH_ECC_REGS register values.  UNC_ERR_ADDR_LOW and UNC_ERR_ADDR_HIGH registers will give the addresses where the un-correctable ECC errors are found.  You can use this to debug further.  

    One thing to note regarding ECC programming:  When using Fapi_AutoEccGeneration programming mode, Flash API will calculate the ECC and program the ECC along with the Flash main array contents. This programming mode expects either 64-bits (minimum) or 128-bits (maximum) of main array data since 8-bits of ECC gets calculated for every 64-bits of ECC. Any unprovided data (in 64-bits) for a 64-bit aligned address will be assumed as all 1s to calculate the ECC. Once ECC gets programmed, you can not program any 1s as 0s in that 64-bit data.  Note that there are practical implications of this when writing a custom programming utility that streams in the output file of a code project and programs the individual sections one at a time into flash. If a 64-bit word spans more than one section (i.e., contains the end of one section, and the start of another), values of 0xFFFF cannot be assumed for the missing data in the 64-bit word when programming the first section. When you go to program the second section, you will not be able to program the ECC for the first 64-bit word since it was already (incorrectly) computed and programmed using assumed 0xFFFF for the missing values. One way to avoid this problem is to align all sections linked to flash on a 64-bit boundary in the linker command file (check out the Flash linker command files given in ControlSuite) for your code project.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Genius 10470 points

    Vamsi,

    Thanks for your info.

    We'll take care of these points when programming.

    Another issue, at the end of user application code programming, there are some extra 0xFFFF will be programmed into Flash, also in ECC auto generation mode. These 0xFFFF are not application code. We found that, the corresponding ECC values are different for Flash content 0xFFFF. Our questions are:

    1) Will these extra ECC (from Flash content 0xFFFF) cause any issue?

    2) Why are these ECC values different for the same flash content 0xFFFF?

    Br, Jordan

  • 0 in reply to Jordan Zhou
    TI__Guru* 87155 points

    Jordan,

    1) Once you program any data (even 0xFFFF) with ECC, you can not reprogram those locations unless you erase that particular sector.

    2) As explained in the TRM, address is included in the ECC calculation.  Hence, even though the data is 0xFFFF like erased locations, ECC will be different.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Genius 10470 points
    Vamsi,
    Thanks for your info.
    I may confuse you about the first question "Will these extra ECC (from Flash content 0xFFFF) cause any issue?". We want to know, if extra 0xFFFF are programmed in Flash content, extra ECC will be programmed. These two extra parts are not customer's application code, but they are programmed. The extra Flash content 0xFFFF will not cause any issue for their application code. What about extra ECC values, will them cause any NMI or other issues to their application code?
    Br, Jordan
  • 0 in reply to Jordan Zhou
    TI__Guru* 87155 points

    Jordan,

    That should not cause any issue as long as those locations are not reprogrammed.

    Thanks and regards,
    Vamsi

  • 0 in reply to Vamsi Gudivada
    TI__Genius 10470 points
    Vamsi,
    Thanks a lot.
    Br, Jordan