• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 82 subscribers
  • Views 223 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.

TMS320F28379D: Booting in wrong mode

Felix van Oost
Prodigy 20 points

Part Number: TMS320F28379D
Other Parts Discussed in Thread: C2000WARE

I'm developing software for a custom board with an F28379D and am having issues getting it to boot correctly in standalone mode. When programming with a debugger and leaving it connected, the code executes normally. If I try to reset the CPU (Ctrl + Shift + R), the system stays stuck somewhere in boot ROM. The same thing happens after a power cycle with no debugger connected. I am trying to get the system to always boot from Flash.

I loaded the boot ROM symbols (ROM version is Rev. B) in CCS and found that CPU1 is stuck in the Parallel_GetWordData() function (specifically in a while loop while(HOST_DATA_NOT_RDY) { }). The boot status at address 0x0000 002C is 0x0D00 (boot ROM started, DCSM init completed, and all resets handled). The CPU1 boot mode at address 0x0000 0038 is 0x0, indicating the parallel boot mode (which explains why it's getting stuck there).

I probed the two boot pins GPIO72 and GPIO84 and can't seem to find any issues (both are HIGH, indicating the 'Get' boot mode and not the 'Parallel' boot mode). The pullups are both 5.1k and the pins are both read as a logic 1 in the GPCDAT register.

BMODE in Z1_BOOTCTRL is set to 0x0B (Flash) as expected.

I also looked at the BootMode variable in the BOM symbols and confirmed that it is indeed 0 (parallel mode). The EmuKey variable is also set to 0x00A5, which is strange because it also indicates the parallel boot mode (something I never specified). If I set EmuKey to either 0x0BA5 (boot to Flash), 0x03A5 ('Get' boot), or 0xFF ('Standalone emulation' mode) using a debugger and then reset the CPU, the system boots to Flash as expected and runs normally. This also works if I run the EMU_BOOT_FLASH GEL script, but I don't know why the default GEL script doesn't do this automatically (I've used other C2000 devices before where this extra step wasn't needed). Is there a setting I can configure somewhere to always boot from Flash in emulation mode? Of course, this stops working after a power cycle and the system remains stuck again.

The EmuBMode variable in the boot ROM is set to 0xA796, which doesn't correspond to any GPIO pins that are available on the system (0xA7 = GPIO165, 0x96 = GPIO149). Not sure where that value is coming from either.

I have the same issue on my board when using the 'empty_driverlib_project' in C2000Ware 3.04, so I suspect this might be something hardware-related.

Does anyone have any input?

  • 0
    Prodigy 20 points

    Correction: All the values in Z1_BOOTCTRL are actually 0xFF:

    I've also tried this on two separate boards, both are acting the same way.

  • +1 in reply to Felix van Oost
    TI__Guru** 116021 points

    Hi Felix,

    Felix van Oost said:
    The EmuKey variable is also set to 0x00A5, which is strange because it also indicates the parallel boot mode (something I never specified)

    If EmuKey is set as "Parallel Boot" then at power-up ROM code is detecting boot mode as parallel boot only because ROM code write detected boot mode to EmuKey. Since you are seeing 1/1 value on BOOTMODE pins, it could be because of some noise during power-up or if you have connected these pins to some active drivers on board then that may be driving them to '0' during power cycle. I would suggest to connect the scope on these pins and try to capture the low value if it ever happens.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Prodigy 20 points

    I got a scope capture of the two boot pins and it was indeed a power domain issue. Thanks! Sweat smile