TMS320F28388D: Standalone Booting Problem

Hi Josel,

Some thoughts:

• Standalone Flash boot will only be entered if both pins are high at the precise moment the bootROM checks the boot pins values. Any fluctuation at that time will affect the boot flow. For example, if GPIO84 is read as LOW when GPIO72 is HIGH, the boot ROM selects SCI/Wait Boot instead of Flash. If both are read LOW, it selects Parallel IO Boot. Either way, the point is the device enters a peripheral bootloader wait state and can appear "stuck."
• Regarding GPIO92 specifically: GPIO92 = I2CA SCLA (I2C clock). If the I2C boot mode is entered (which could happen depending on which pin combination is misread and what the OTP BOOTDEF table contains), the I2C bootloader would configuresGPIO92 as the I2C master clock output. The MCU is waiting in the bootloader, and touching GPIO92 with a finger or jumper injects electrical disturbance on the I2C SCL line, and can disrupts the I2C peripheral, triggering a change.
• Why JTAG always works: Figure 5-1 (p. 723 of TRM) shows that when a debugger is connected, the boot ROM takes the Emulation Boot path (Figure 5-2), which reads EMUBOOTPINCONFIG — a RAM register — instead of the physical GPIO pins. The GPIO72/GPIO84 state is completely irrelevant in emulation mode. This is why JTAG always succeeds regardless of the pin issue.

A few suggestions to gather more info and debug:

1. Read Boot Status Register

• While the device is in its "stuck" state, connect JTAG and in CCS Memory Browser read address for CPU1 Boot ROM Status, Table 5-68, p. 766 of TRM.
• Also, check CPU1 Boot Mode, Table 5-74, p. 769 of TRM — this records which boot mode was decoded.
• This info can help confirm exactly what the boot ROM entered. The "stuck" state you observe is likely the ROM waiting in a peripheral bootloader loop.

2: Hardware-Related

• A. Try lower resistance pull-up resistors on GPIO72 and GPIO84
• B. View GPIO72, GPIO84, and XRSn with a scope at power-up to confirm expected values/timing
• C. View power supply check with a scope at power-on to confirm expected values/timing
• D. Try the test with the connectors physically removed

3. Possible Fix if I2C Boot is Confirmed

• If the boot status register confirms I2C Boot, one possible fix would be to program the OTP BOOTPINCONFIG to explicitly assign GPIO72 and GPIO84 as BMSPs with Key=0x5A, removing any dependency on pin sampling timing. Section 5.4.1 (p. 718 of TRM) describes how to configure this. 

Best Regards,

Allison

Hi Allison,

The same issue i faced also with the control card ( F28388D ). First it is not possible to debug the control card unless there is external 5V over docking station. after successfully loaded program to flash it does not starts in the standalone mode. When i touch the GPIO92 in docking station pin number 161 it starts to run. the test program is example from TI blinky. I never changed the OTP program, it is like factory default. It is a little bit confusing right now. I already checked the boot select pin status. They are both high at the beginning. I ´m confused because this is brand new MCU and i do not want to change the OTP program form default. But this behavior is a little bit strange. even the same issue in control card happens i really do not have any idea how to use this MCU properly. or i m making some mistake externally. But i do not have a real idea.

Regards,

Josel

Hi Josel, 

Were you able to connect to the device after powering-on so that you can read the registers I suggested? Can you send images of the scope from the hardware related suggestions as well? 

Unfortunately I'm not sure I have a good understanding of what you have already done to debug this- it would be helpful if you could provide a step-by-step of your procedure (e.g. before touching the GPIO, what is the state of the device, and are you able to simply power on the controlcard + docking station and connect to the CPU in CCS at all?). Details like this are important to help me narrow down the scope of what is happening. 

Best Regards,

Allison

Allison,

During the observed “stuck” state, when attempting to connect to the MCU using CCS or UniFlash, the CPU appears to be halted. Reading the 32-bit value at register address 0x00000002 in Memory browser is 0x00000000 (all bits cleared).

In debug mode, I performed a test by pressing the reset button on the control card. This action stops the LED blinking application; however, the CPU remains in a running state according to the Debugger in CCS. When reading the same register (0x00000002) in this condition, the value is 0x8001300B. I am not certain whether this value matches the one in the standalone “stuck” condition.

The behavior is similar in standalone mode. Pressing the reset button stops the LED blinking. If I then touch GPIO92 with my finger, the LED starts blinking again. However, in debug mode (when connected via CCS), pressing reset is not sufficient—touching GPIO92 does not resume operation, and the MCU program must be manually restarted from the debugger.

Additionally, I am currently unable to connect to the MCU via the J1:A USB emulation interface on the control card, even when supplying external 5V power and with switch S1:A Position 1 set to ON. At present, I can only debug the control card via the external JTAG connector.

According to the Control Card Information Guide:

S1:A Position 1 – JTAG Enable
ON: All signals between the XDS100v2 emulation logic and the MCU are connected. This setting is valid when the MCU is being debugged or programmed via the on-board XDS100v2 emulator.

Based on this description, I would like to clarify: if the device has previously been programmed via the external JTAG interface, is it still possible to program or debug it using the on-board XDS100v2 emulator, or could this configuration prevent access via USB emulation?

Regards,

Josel

Hi Josel,

Address 0x00000002 is correct for the CPU1 BootROM Status register (Table 5-68, TRM p. 766). Per the TRM (§5.7.11.1), this register is cleared on any POR or XRS reset- the 0x00000000 may not reflect the actual stuck-state boot mode.

Regarding the 0x8001300B in debug mode after pressing reset: This decodes cleanly:
- Bit 31 = Boot ROM finished running
- Bit 13/12 = XRS Reset handled
- Bits 7:0 = 0x0B = Wait Boot

The last part explains the debug behavior. After pressing reset in a CCS session, the bootROM enters the emulation boot path and defaults to Wait Boot- the CPU sits in a wait loop and must be manually restarted from CCS. Touching GPIO92 has no effect here because the emulation boot path doesn't use any GPIO boot pins. This behavior is normal and expected in debug mode and is separate from your standalone issue.

Regarding XDS100v2: Prior external JTAG programming doesn't block it. The controlCARD schematic (Sheet 10) shows S1:A Position 1 is a hard selector between the two interfaces- ON connects the XDS100v2, OFF connects an external emulator. They can't be used simultaneously. Make sure S1:A Pos 1 = ON and the external JTAG cable is unplugged, then retry the USB connection.

Next steps:

1. Get the non-reset stuck-state register value- power on without JTAG, wait for the stuck state, then connect CCS to attach to running target (no reset). Read 0x00000002 and 0x00000004 and share the values to help confirm which boot mode the ROM entered. We need to clearly understand the state of the device in the "stuck" state.
2. Try to fix the XDS100v2- set S1:A Position 1 = ON and physically unplug the external JTAG cable, then retry USB connection.
3. While waiting on the register read- (I see you already tried varying resistance, but would like to cover bases) can you try lowering the pull-up resistor values on GPIO72 and GPIO84. The controlCARD pull up is relatively weak; try 4.7kΩ or lower. If the stuck state goes away, that confirms the boot pins were not reaching a stable HIGH before the bootROM sampled them.

Best regards,
Allison

Hi Allison,

I have already tried to read the registers as I mentioned, but it is impossible to connect to the CPU over CCS while it is running as you expected. Whenever you attempt to connect, the target CPU is suspended.It is not running state anymore.

As I said, in this suspended state the registers read zero (0x00002 and 0x00004). If I then start the CPU again in debug mode, it is no longer stuck.
The only possible way to read these registers is while the CPU is suspended.
Regarding the other issue: I have set S1:A to position 1 (ON), and the JTAG connector is unplugged. This is exactly the point—I can say that I have read and applied almost all standard solutions mentioned in the TRM and TI forums, but I am still unable to move forward.
I also tried again using a 4.7 kΩ resistor, but it made no difference.
Are you able to reproduce this issue with your control card, if you have one? I am a bit skeptical because both my custom-designed board and the control card show the same behavior.

Regards,

Josel

Hi Josel,

To confirm, when you connect to the CPU, are you using real-time debug mode where there is no reset upon connection to the CPU? e.g. explained two ways in the two threads linked by Ben here:  TMS320F280039C: Connect CCS debugger without resetting the part .

Forgive my repetition in asking, but you have you also scoped XRSn, boot pins, and power during power-on as well to look at the timing, correct?

I have unfortunately not experienced this issue with standalone boot to flash on an F2838x controlcard as of yet. 

Best Regards,

Allison

Hi Allison,

Yes, I am using real-time debug. I already changed the debug configuration so that the target is not reset when the debug session starts. However, in any case, the target is still suspended. Even with the settings mentioned in that link, the target is expected to be suspended (even if it is not reset).
As I mentioned, the device is not being reset, but it is suspended. I could not find any information stating that it is possible to connect to the target CPU without it being suspended (i.e., directly in a running state). I think this is not possible with CCS.
I have also checked the XRSn pin with an oscilloscope, and it remains constantly high. The boot select pins, supply voltages during startup, and reset pin behavior all match the specifications in the TRM. Additionally, during the stuck state, the CPU does not respond to the XRSn pin. When I try to reset the CPU via the XRSn pin, there is no reaction—it does not reset.
Could this be related to CPU2 or the CM?

Regards,

Josel

Hi Josel,

Thank you for the follow up. Please allow another day for me to discuss with a team member regarding the issue.

Best Regards,

Allison

Hi Josel,

Apologies I still haven't recreated this. I will provide a status tomorrow on progress.

Best Regards,

Allison