• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 784 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.

DM8148 BTMODE pins

Eric Bryan
Expert 1045 points

Can we tie the BTMODE pins directly to 3.3V and GND to configure if we are not using the NAND boot modes (say model 10110 SPI/MMC/UART/EMAC)?  Saves us a lot of traces we have to route into a crowded device.

  • 0
    TI__Guru**** 170625 points

    Eric,

    I am not sure I fully understand your question. Do you need to hardcode the BTMODE pins to 10110 (SPI boot), instead of using a boot switch? Thus you will be able to boot only from SPI flash.

    Regards,
    Pavel

  • 0
    TI__Genius 13460 points

    I wont recommend you to do so.

    BTMODE pins are muxed w/ GPMC pins.  If Pull-up/down is too strong, it will surely cause problems.

  • 0 in reply to Eason Wang
    Mastermind 8040 points

    His point is that he's hardcoding a boot order which doesn't include any boot mode which would cause the ROM bootloader to mux those pins to the GPMC.  As long as the pins remain muxed to safe mode (the reset default) they will always be high-Z and tying them to gnd / dvdd_gpmc externally should indeed be safe.

  • 0 in reply to Matthijs van Duin
    Expert 1045 points

    This is exactly the case.  I will confirm when we physically test this.  By tying these lines directly, without resistors, we save a lot of routing space going in and out the device and our layout is rather tight.  We really don't want to go to smaller geometry design rules.

  • 0 in reply to Eric Bryan
    Mastermind 8040 points

    You should be able to confirm this on an EVM also: if you configure BTMODE to 10110 as you suggested then the bootmode/GPMC pins (pincntl registers 89-104) should remain unmuxed (lower halfword zero) even when ROM tries all four boot devices.  This should remain true with a suitably built u-boot in SPI or MMC.

    Don't forget to check the pin usage for all boot devices in the chosen boot order (even if you don't intend to support them all) to ensure no drive conflict occurs with your intended use of the pins when an unprogrammed device cycles through them.  The pinmux for Ethernet also depends on other BTMODE pins.

  • 0 in reply to Matthijs van Duin
    Expert 1045 points

    Yes, I didn't make that clear--we are tying the upper BTMODE pins as well but again, we don't use them or configure them after restart.  I am making sure the software guys don't allow any programs to reconfigure these pins either!

  • 0 in reply to Eric Bryan
    Expert 1045 points

    This appears to be working on our system without any problems.