• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 81 subscribers
  • Views 660 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.

Questions about setting boot modes for the 28035 and XDS100v1

James Smith6
Prodigy 60 points

Hello,

We have made a prototype/dev board with the 28035 Piccolo and an on board XDS100v1. Everything works fine with the debugger and getting code to run.  We would like to run the controller from flash but we are having a hard time doing it and it looks like we may have screwed it up pretty good.  At any rate, I was wondering if you guys could clarify a few things for me.

As I understand it there are 3 ways to instruct the 28035 on where to boot from:

1. With an Emulator using the EMU_KEY and EMU_BMODE bits of the PIE vector table which resides in RAM.

2. No Emulator using GPIO37/TDO and GPIO34

3. Using the OTP registers (ONE time programming)

Option 2 is pretty much gone because we did not install jumpers for the TDO pin and GPIO34 is used else where and would require significant board hacking to gain access to.

I would prefer to avoid option 3 as these are dev boards, idea being they can be flexible for future use.

Pretty much leaves just option 1.  This requires an emulator to be connected, but I was wondering if there is a way to set up the EMU_KEY and EMU_BMODE bits so that they will survive a power cycle (it appears they are in RAM?).  I should be able to test the code with these bits set how ever I want (though the GEL file or a script in CCSv5), but I am wondering if this requires that an emulator actually be connected or if I can just pull the TRST pin low and use the EMU bits to boot from flash (or where ever I want it to boot from)?  I should be able to then connect a debugger to change the bits and therefore the boot mode.

Is that possible or am I stuck until I program the OTP?

Thanks,

Jim

  • 0
    TI__Guru 57255 points

    Hi Jim,

    Before we rule out (2), what are TDO and GPIO34 pulled to? 

    For TDO I assume it's floating when no emulator is connected and therefore its being pulled high by the internal pull-up.  This is good for us.

    Is GPIO34 being controlled externally?  Pulled low by a resistor?


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 60 points

    Brett,

    Thanks for the fast reply.

    GPIO34 is a power status signal for a 12V supply.  This will either float or be pulled low by an external IC depending on the status of the supply.  That supply may or may not be used at all times, so I cannot guarantee that the pin will be in a known state.  There could be a simple way to tie the pin high or low and just ignore the Aux power supply status as it is not particularly needed anyway. This pin also feeds into a Bi-Directional logic translator, so if I could force the GPIO pin to initialize low the logic translator would probably be OK with that and not force it high (the use of that logic translator on this signal was incorrect, but its there so I have to deal with it...).

    The emulator is an XDS100v1 and is on board, its permanently attached to the board and I am not quite sure what the pins do when you power the board up the board but do not attach it to a computer or connect to it though Code Composer.

    The murkiness of this situation is kind of why I wanted bypass it.

    Thanks,

    Jim

  • 0 in reply to James Smith6
    Prodigy 60 points

    Probing the board here is the situation:

    TRST pin is held at 0 volts by the emulator if it has power and I am not connected to it in Code Composer.

    TDO is held at 3.3V by if I am not connected to the emulator in Code Composer

    GPIO34/Aux Power can be held at about 0V

    Jim

  • 0 in reply to James Smith6
    TI__Guru 57255 points

    Jim,

    The on-board xds100v1 shouldn't cause you an issue.  When it's not being used TDO will get pulled-high and TRSTn will be low (which is what you are seeing).

    I believe the issue lies with GPIO34.  If you can put PWR_GOOD signal into a floating state the pull-up inside the device should take over and pull the pin high.  This will put the device in Get mode (boot to flash by default).  You could then at least prove that the device boots as expected on your custom board.


    Thank you,
    Brett

  • 0 in reply to Brett Larimore
    Prodigy 60 points

    Brett,

    Thank you very much, this does work.  The board will boot from flash and start executing code.

    However, this required a little bit of surgery on the board.  I would like to avoid repeating this surgery in the future.  Is there a way I can force a boot from flash (or boot from anywhere) while GPIO34 is being actively held low? 

    Jim

  • 0 in reply to James Smith6
    TI__Guru 57255 points

    Jim,

    Well that's at least something. :)  I don't know if it helps, but GPIO34 is really only polled during the boot process.  Afterward you can use the pin freely.

    Unfortunately, to survive a power cycle I believe you're stuck with only option (2) and (3).  Option (1) is really only meant as a way to help debug the boot process with the emulator connected, it's not really meant to do what you want.


    Thank you,
    Brett