• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 81 subscribers
  • Views 208 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMDSDOCK28035: TMO vs GPIO37 to select OTP Get_Mode

Jeffrey Masse
Intellectual 360 points
Part Number: TMDSDOCK28035

The F28035 requires GPIO34 == 1 and GPIO37 == 1 in order to get into OTP_Key Boot Mode GetMode selections. However, on the TMDSDOCK28035, GPIO37 is TDO which is used for the JTAG. How does one wire up the DOCK in order to get into the OTP_Key Boot Mode GetMode CAN bootloader while developing and debugging? Do I need to put a pull up resistor on GPIO37/TDO when in OTP mode with no emulator and then pull it off when I want to use the emulator again? (Add a switch the the DOCK so pullup closed/open?)

  • 0
    TI__Mastermind 30825 points

    Hi Jeffrey,

    Your query has been received  and an expert will be assigned to it shortly. 

    Best Regards

    Siddharth 

  • 0 in reply to Siddharth Deshpande
    Intellectual 360 points

    Thank you, I have another related question:

    If I want to boot the DOCK to EMU SCI Boot mode, GPIO37/TD0 needs to be low because I am testing how to send a hex file via SCI. Ensure the Tx/Rx connections, C2Prog.exe usage etc... How do I set GPIO37/TD0 low and still use the emulator?

  • +1 in reply to Siddharth Deshpande
    TI__Mastermind 25331 points

    Hi Jeffrey,

    You are correct, per the device datasheet the GPIO37 pin cannot be used to select the boot mode when the JTAG debug probe is selected. In this case, the datasheet mentions the use of SARAM locations to select the boot mode.

    When the JTAG debug probe is connected, the GPIO37/TDO pin cannot be used for boot mode selection. In this case, the boot ROM detects that a JTAG debug probe is connected and uses the contents of two reserved SARAM locations in the PIE vector table to determine the boot mode. If the content of either location is invalid, then the Wait boot option is used. All boot mode options can be accessed in emulation boot.

    Jeffrey Masse said:
    How does one wire up the DOCK in order to get into the OTP_Key Boot Mode GetMode CAN bootloader while developing and debugging? Do I need to put a pull up resistor on GPIO37/TDO when in OTP mode with no emulator and then pull it off when I want to use the emulator again? (Add a switch the the DOCK so pullup closed/open?)

    Specifically to your question, you can put a pull-up resistor on GPIO37/TDO to select the boot mode in non-JTAG mode. When using JTAG mode, the pull-up should not interfere with the JTAG operation as long as it's the right size (i.e. MCU output buffer can drive VOL on that pin). In JTAG mode use the SARAM locations mentioned in the datasheet to select the boot mode.

  • 0 in reply to Jeffrey Masse
    TI__Mastermind 25331 points

    Please see the previous response about selecting a boot mode in JTAG mode.

  • 0 in reply to Gus Martinez
    Intellectual 360 points

    OK - So now I am trying to use the EmuKey and EmuBMode of PieVectTable 0x0D00 0f 0x55AA and 0x0D01 of 0x0001. This should boot the DOCK kit into SCI mode. Hardware wise I need a USB to RS232 to SCI (5 volt logic). Then connect the Tx to SCIRXDA (GPIO28) and Rx to SCITXDA (GPIO29). Correct? This should be sufficient to allow me to load a hex file via the C2Prog application?

  • 0 in reply to Jeffrey Masse
    TI__Mastermind 25331 points

    Jeffrey,

    GPIO28 and GPIO29 get routed to the FT2232D on the docking station through the isolation device on the controlCARD. You should be able to communicate with the MCU via SCI through the COM port that shows up on your PC. You do not need a separate USB to RS232 on the docking station, the FT2232D already provides this functionality.

  • 0 in reply to Gus Martinez
    Intellectual 360 points

    Yeah - I just discovered the Tx/Rx of the DOCK and that greatly helped.

    So I am running the FlashingLeds-F28035 example in which when executed in CCS, will load the Flash with the Flashing Leds program. I have updated the Emu_Key to 0x55AA and Emu_BMode to 0x1. I then Run (debug) in CCS and I see the program get loaded to Flash (Erase and all). I press Run at Main() and then I hit Reset CPU in CCS and then Run again (at address 0x3ff8a1). (Now the LEDs have stopped flashing so I believe I am in SCI Boot Mode.) I then use C2Prog to try to load the hex file via SCI. The Autobaud is works and I can see a lot of data transfer via an attached O'Scope. However the C2Prog window ends with "Bootloading... failed (no response)!".

    What may be preventing the success of the Flashing Leds hex file via SCI?

    Hex file creation - Properties/CCS Build/Steps/Post-Build Steps add - "${CG_TOOL_HEX}" -i "${BuildArtifactFileName}" -o "${BuildArtifactFileBaseName}.hex" -order MS -romwidth 16

  • 0 in reply to Jeffrey Masse
    TI__Guru* 84475 points

    Jeffrey,

    Maybe you can simplify things by programming the chip with C2Prog by means of a clean reset into SCI bootmode (using the DIP switches on the controlCard). 

    If you have further questions, please contact Codeskin at  info@codeskin.com.

    Thanks and regards,

    Vamsi

  • 0 in reply to Vamsi Gudivada
    Intellectual 360 points

    Yeah - using dip switches or GPIO for correct boot mode on power up works. I will poke t getting EMU mode to work as a learning process. Thanks.