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.

TMS320F28375S: Failed booting from Flash, happens randomly

Part Number: TMS320F28375S
Other Parts Discussed in Thread: C2000WARE

Tool/software:

Hello

I am experiencing a weird problem. I have a bootloader flashed in the first two flash sectors and running from flash. Then I have a few sectors left empty. Actually they are reserved for a second bootloader, but for now They are empty. Then there is a place in flash for the main application. 

Consider this:
In the bootloader code, I make a small and insignificant change to just get two different checksums (I only change the value of a defined macro, which is not even used in the code). So I get two different versions of the Bootloader. let's call them BL0_v1 and BL0_v2
I flash each one on the DSP (and there is nothing else flashed, only that bootloader. No application). And both run normally.
Case 1: BL0_v1 ==> OK
Case 2: BL0_v2 ==> OK


Then in another case, I also flash the main application besides the bootloader. In this case, with one of the bootloaders, the dsp doesn't boot, even after a power cycle! 

Case 3: BL0_v1 + APP ==> OK
Case 4: BL0_v2 + APP ==> Does't run!! 

I repeat again that the difference between BLv_v1 and BL0_v2 is insignificant. So whatever is causing this problem is not about the content of that small change. It happens randomly, and it has happened also by small changes in other parts of the code as well. 

My question is that what could possibly be the reason of this problem? Why it happens randomly? If there is something wrong in the Bootloader code BL0_v2 (which there isn't, because v2 is essentially the same as v1), why that issue happens only when the App is also present and not without the app? 

I have developed a two stage bootloader and I noticed this issue during my tests. this BL_0 is actualy the first stage loader.
At first I thought the issue is from the second stage bootoader that was developed, because during my development, sometimes just by a small change in the stage 2 bootloader something similar would happen and the dsp would just die after a reset. (During those tests I didn't change BL0). Then I noticed that even with some changes in BL_0 and without the second stage BL, This issue could happen. I appreciate any ideas bout the cause of this issue.





  • Hi Saeed,

    What do you mean by the DSP not booting after reset? Have you tried debugging the boot ROM to see where the DSP is getting stuck?

    You can step through the device boot ROM by loading the boot ROM symbols (.out file) to the device. This option adds the symbols available in the generated project '.out' file for debugging purposes instead of loading the actual '.out' program onto the core via CCS - this is also why you can use this method with the boot ROM/built in bootloaders to debug and get visibility.

    1. Open CCS to a workspace
    2. Click 'view' > 'target configurations':
    3. You can import a project for this device to CCS and use that to connect to the device, or copy the raw target config from C2000Ware to the "user defined" target configurations in this window. Either way, find the device target config (example for F28375S below) and launch it:
    4. When it brings up the debug window, select the device CPU and connect to the target:
    5. Navigate to the toolbar and click the button to "load symbols"
    6. Load the boot ROM .out file. For this device, it should be in 
      1. C:\ti\C2000Ware_5_04_00_00\libraries\boot_rom\f2837xs\revB\rom_sources\ccs_files\cpu01\Release
      2. If a window pops up saying it can't find the source file, you can select "Locate File" and find it in C2000Ware
        1. Usually here C:\ti\C2000Ware_5_04_00_00\libraries\boot_rom\f2837xs\revB\rom_sources\F2837x_bootROM\cpu01-bootROM\source
    7. The file should open to show the location of the boot ROM you are at, and you can step through/debug

    Best regards,

    Matt