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.

L138: errata sheet’s BOOTMODE strong pulling resistors

Hi,

We had some problem with the BOOTMODE[7:0] pins. After burning the AIS image into the flash and setting the correct BOOTMODE pins per table 11 in SPRAB41D, whether the device could boot from the selected mode is intermittent. In fact, for about ½ of the times the boot is successful, and there is about a half’s probability that the device doesn’t boot.

After then connecting to the device using emulator and running the debugging GEL file found on TI wiki,

  1. After successful, it tells us that boot was successful
  2. If the boot fails, it tells us that BOOTMODE is invalid

 

We checked L138 silicon errata SPRZ301H and “Advisory 2.1.23 BOOT: Internal Pullup Resistors for BOOT[7:0] Pins Are Sometimes Enabled During Reset, Leading to Boot Failures” advised strong pull-up/down resistors. We use 1.8V I/O voltage and 2Kohm seems to suit both pull-up and pull-down case.

We have two questions:

1.  2kohm is a very strong pulling. The BOOTMODE[7:0] pins are also shared with LCDC_D[15:0] output, so does L138 have driving capability strong enough to overcome the 2Kohm pulling-up/down so that LCD could always see the correct signal?

2. Using strong pulling means larger quiescent. For BOOTMODE[7:0], the configurable pulling group is CP[29] (SPRS586C 2.8.11 Boot), and the default pulling value is 0 (SPRUH77 Table 11-55). Since we are not going to pin programming all BOOTMODE[7:0] pins to the same value so that some will be pulled to 1, then either if we configure CP[29] to 1 or 0, we will always have some opposite pullings, and according to http://processors.wiki.ti.com/index.php/Optimizing_IO_Power_Consumption some leakage is unavoidable. Is this true?

In order to calculate the leakage current we need to know the internal pulling resistance. Can this be calculated from silicon errata “Advisory 2.1.23 BOOT: Internal Pullup Resistors for BOOT[7:0] Pins Are Sometimes Enabled During Reset, Leading to Boot Failures”?

 

Paul

  • Hello,

    All these electrical specs (and more) can be found on sprs586d.pdf, recommended op conditions (5.x):

    IOL / IOH = 6mA, compared to #1 mA with 2 Kohm @ 1.8V

    Input leakage = -270 / 310 uA max when opposing internal resistor.

    The 2K ohm leads to 0.6V max drop when opposing at boot. Do not use more than 2K at 1.8V: 2.2K is the pull-down limit before crossing VIH (0.65*VDD=1.17V).

    Jakez

  • Hello again,

    Forgotten this (untested) suggestion in preceding post:

    If  the nRESETOUT pin keeps its function during normal operation (output with no PINMUX modification), you can use it in a simple way to set the boot pins state. By direct connection of all the 2K boot pull-downs to the open-drain nRESETOUT instead of VSS, there's no more leaks for pull-downs. This assumes the Advisory 2.1.23 errata never involves a pull-down initialization of the OMAP chip, so only high value resistors (say 20K) are required for boot pull-ups.

    As the nRESETOUT pin belongs to the same power group than the BOOT pins (ie group C), this is compatible with any I/O power configurations.

    Jakez

    Edit: In this configuration, all pull-downs BOOT pins are interconnected through the 2K resistors; so there's in fact still a leakage from pin-to-pin, but it's half the initial leak in the worst case. If it is still too much, the 2K resistor can be replaced by 1K resistor and some Schottky diode in series.

    At this point, you can use a low power 8-bit 3-state buffer enabled by the nRESETOUT pin (with a weak pull-up, as it is open-drain) to drive the BOOT pins.

  • Jakez,

    We have followed the calculation on current, it’s correct. A minor possible correction is that the limit for pull-down resistor would be 2.33K? This is by 0.35x1.8/270uA=0.63V/270uA=2.33K, same as the errata value.

    Regarding your updated post on using nRESETOUT, since you have an “untested” comment at the beginning, has this been tested on any of the EVMs? This might be a more perfect solution but even using 2K pulls the leakage during operation is still acceptable for us.

     

    Paul