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.

TMS320F28035: bootloader modes choose when debugging a locked device

Part Number: TMS320F28035


Hi,

In TRM it says:

This device does not support the hardware wait-in-reset mode that is available on other
C2000 parts. The "wait" boot mode can be used to emulate a wait-in-reset mode. The "wait"
mode is very important for debugging devices with the CSM password programmed (that is,
secured). When the device is powered up, the CPU will start running and may execute an
instruction that performs an access to an emulation code security logic (ECSL) protected
area. If this happens, the ECSL will trip and cause the emulator connection to be cut. The
"wait" mode keeps this from happening by looping within the boot ROM until an emulator is
connected.

I'm curious about the statement, when we debug the device with XDS200 and CCS, since XDS200 is connected to the board and PC, /TRST pin should be pulled high to Emulation Boot mode, right? Then the boot mode is irrelevant to GPIO 34 and GPIO37. Right?

But when I tested on our controlcard when the F28035 is locked and GPIO34=1, GPIO37=1. I'm not able to connect the device with CCS and XDS200.

When I configure GPIO34=0, GPIO37=1, I'm able to connect the device with CCS and XDS200.

  • Hello

    Yes, I would expect TRST to be high and therefore the GPIOs are irrelevant since you'll be doing emulation boot.

    Your test sounds to align with the TRM? Can't when going to Get mode, but you can when you go to wait boot mode.

    Best regards

    Chris

  • Your test sounds to align with the TRM? Can't when going to Get mode, but you can when you go to wait boot mode.

    But as you said, the boot mode is irrelevant to the GPIOs when XDS200 connected, why can I configure the bootmode by configure the GPIOs?

  • Hello

    From what you observe, I suspect that the TRST isn't getting set when device is locked and debugger is connected. That would be the only way for the GPIOs to control the boot mode with debugger connected.

    Let me double check with team experts.

    Best regards

    Chris

  • If that's the case, Then when will TRST be set?

    I'm curious about the conditions TRST is set.

  • Howard,

    I think the issue is that the emulator may not be driving TRSTn pin continuously.  I suspect that until you "connect" inside of CCS that TRSTn is not being driven actively.

    Assuming that is the case, as soon as XRSn goes inactive high the MCU will begin the boot process and if TRSTn is not driven high it will proceed to the normal boot flow looking at the GPIO pins.

    I beleive that EMU Boot is intended to be used once you are connected, so that a customer can observe the boot mode they will use while still connected to the emulator.

    Let me know if you have more questions.

    Best,
    Matthew