• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 4 answers
  • Subscribers 83 subscribers
  • Views 823 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.

GPIO Boot Pins

James Stanley
Prodigy 160 points

Other Parts Discussed in Thread: CONTROLSUITE

The Technical Reference Manual describes various boot modes that can be configured to control whether the device boots frrom Flash, RAM etc. How are these GPIO pins configured on the Concerto controlCARD? Where is this described in the documentation?

Thanks.

  • 0
    TI__Mastermind 22025 points

    James,

    The TRM describes the GPIOs associated with boot mode selection in section 6.3 "Device Boot Modes".  These GPIOs are brought to SW1 on the controlCARD.  You can find a schematic of the board in controlSUITE in:

    C:\TI\controlSUITE\development_kits\~controlCARDs\CCF28M35xxHWdevPkg

    Trey

  • 0 in reply to Trey German289
    Prodigy 160 points

    Thanks Trey,

    Maybe I'm old school, but I'd find it easier if documents like this could be downloaded straight from the TI website...

    Anyway, what I was really after was the reason why I don't seem to be able to run the Cortex-M3 core in stand alone mode, booting from Flash. I know there are various other posts on this forum on this topic, but none of them provides me with the answer. This is what I've got so far:

    SW1: All switches need to be in the '1' position ... which I assume to mean in the 'up' position (when the card is in the docking station)

    SW3: Position 1 (the leftmost switch) needs to be OFF (down)

    main() needs to setup the system clock, PLL etc and call either FlashInit() or FlashSetup()

    Clearly I'm missing something as this does not let my code run. The code runs fine from the debugger (with SW3 position 1 in the ON state).

    Another thing I don't follow is what happens when I select "CPU Reset" from the debugger. SP get's reset to 0x20004900 (which I guess is reasonable) but PC gets reset to 0x01001566 which I don't understand. If I hit "Resume" at this point, my code doesn't run. However, if I instead hit "Restart", I get put back to the start of main with the SP reset to that defined by the linker script. What does CCS do when I select "Restart"?

    James.

  • 0 in reply to James Stanley
    TI__Mastermind 22025 points

    James,

    I understand your frustration with having to download controlSUITE.  I agree that we could do a better job distributing our software and documentation and this is something we are working on internally.

    You've got the right idea with the switches but there is one problem.  On SW1 all of the switches need to be in the down position.  Try running the dual core blinky example, each core flashes one of the LEDs on the board.  Its an excellent example to start with if you want to build a stand alone boot from flash application.

    The PC points to 0x01001566 because that is what the reset vector points to.  Take a look at address location 0x04 (the reset vector).  The reason the code doesn't run when you hit run after resetting is that the bootROM runs first.  The bootROM can tell whether an emulator is connected or not and if an emulator is connected it does a special emulation boot.  Instead of looking at the boot mode pins the bootROM instead looks at some memory locations to figure out how it should boot.  This is all documented in the bootROM section of the TRM.  When you hit restart CCS automatically starts execution at cint00 and puts a hidden breakpoint at main.

    Trey

  • 0 in reply to Trey German289
    Prodigy 160 points

    Thanks for clarifying the SW1 switches.

    James.

  • 0 in reply to Trey German289
    Intellectual 700 points

    Trey,

    I have a related question about the boot pins.  The TRM says the following....

    . Boot Mode 7 typically does not
    require any external signals to drive the three boot mode pins, as by default, all three pins are internally
    pulled up to logic 1 (111b).

    My board design leaves 2 of the pins disconnected, and 1 of the pins is connected to a couple of logic gate inputs.  I thought this would be OK if I want to boot to FLASH.  But it's not working.

    I can look at the M boot status bits and see that sometimes it's trying to boot to EMAC and sometimes to Parallel GPIO.  So I checked voltage of all three boot pins.  The disconnected pins are nearly 0V and the one connected to logic gate inputs is around 2.0V.  So my boot bits are sometimes (000b) and sometimes (100b), which perfectly explains why I'm seeing parallel and EMAC booting.  

    Is the TRM manual wrong?  Do I have to tie boot pins high?  Can I not use one of them as a GPIO output to logic gates?

    Thanks,

    Joel 

  • 0 in reply to Joel Clasquin
    TI__Mastermind 22025 points

    Joel,

    When the chip initially boots all the pins are high impedance.  Where does it say the pins are pulled high by default?  If it does say this, I believe this might be a mistake.

    Yes you can use any of the boot pins as either an input or output after the device has booted.  There is nothing really special about these pins.


    Trey

  • 0 in reply to Trey German289
    Intellectual 700 points

    I'm looking at page 41 of the datasheet.  It's the first paragraph under the "Master Subsystem Boot Mode Selection" table (table 2-17 in the January 2012 revision).  

    This is the quote...

    "Boot Mode 7 typically does not
    require any external signals to drive the three boot mode pins, as by default, all three pins are internally
    pulled up to logic 1 (111b)."

    I guess I'll be modifying my board.

    Thanks,
    Joel 

  • 0 in reply to Joel Clasquin
    TI__Mastermind 22025 points

    Don't start modifying your board yet.  The pins by default do in fact have their pullups turned off, but the BootROM code may be enabling these pullups.  Let me check this first.

    Trey

  • 0 in reply to Trey German289
    TI__Mastermind 22025 points

    I just talked with our bootROM author and the pullups are NOT enabled by the bootROM which means these pins are floating on your board.  The input side of the buffers connected to that pin probably have a small leakage which is building up on the pin and causing it to read high.  Please place actual pull up or down resistors on these pins.

    Sorry for the confusion.  This will be correctly in the next revision of the datasheet.

    Trey