TMS320C6652: SPI booting gets suspended after the initial 4 bytes

Hidehito Sato

Part Number: TMS320C6652

Hello,

I need an immediate advice for booting DSP from SPI flash.
I have made a custom board with TMS320C6652 which boots from SPI flash connected to SPISCS0, but the booting process is always suspended after the initial 4 bytes are read by DSP.
Somehow DSP resumes the rest of the booting process either when DSP's DVDD15 power is temporarily turned off for more than 3ms (this violates the power/reset sequence, though) or when DSP is extremely cooled down by a cold spray.

I guessed the RBL of DSP is probably trapped in an infinite loop after reading the first 4 bytes from SPI flash and resetting DVDD15 or putting DSP in low temperature brings DSP out of that loop to continue reading the following data from SPI flash.
I looked over the source code of RBL and narrowed down on the most suspicious loop probably responsible of suspending the boot process.

Line 140 - 144 of spi.c :

/* Clear out any pending read data */
do {
v = DEVICE_REG32_R (DEVICE_SPI_BASE(cfg->port) + SPI_REG_SPIBUF);
v = DEVICE_REG32_R (DEVICE_SPI_BASE(cfg->port) + SPI_REG_SPIFLG);
} while (SPI_REG_SPIFLG_RX_DATA(v));

Does anybody have an idea what can make this loop infinite!?
This loop is within hw_spi_xfer(), which is called by hwSpiRead(), which is called by boot_spi_read_blocked_block() of spimain.c.
I paste a part of spimain.c codes below. I am pretty sure the booting process is suspended between the two hwSpiRead() function calls.

Line 161 - 189 of spimain.c :

void *boot_spi_read_blocked_block (UINT32 *addr, UINT32 *sizeBytes, spiConfig_t *spiCfg)
{
UINT16 *data = spi_boot_tbl_buf;
UINT16 checksum;

/* Read the header */
if (hwSpiRead (*addr, BOOT_SPI_SECTION_HEADER_SIZE_BYTES, data, spiCfg) != 0) {       ←the first hwSpiRead() to read the first 4 bytes
  bootLogEntry ((char *)fname, __LINE__, BOOT_SPI_LOG_READ_FAIL);
  *sizeBytes = 0;
  return (NULL);
}

*sizeBytes = data[BOOT_SPI_HEADER_OFFSET_LENGTH_UINT16];

/* Validate the block size */
if ( (*sizeBytes > BOOT_SPI_SECTION_HEADER_SIZE_BYTES) &&
(*sizeBytes <= BOOT_SPI_MAX_SECTION_SIZE_BYTES) &&
((*sizeBytes & 1) == 0) ) {

      if (hwSpiRead (*addr + BOOT_SPI_SECTION_HEADER_SIZE_BYTES,
          *sizeBytes - BOOT_SPI_SECTION_HEADER_SIZE_BYTES,
          &data[BOOT_SPI_SECTION_HEADER_SIZE_BYTES >> 1], spiCfg) != 0) {       ←the second hwSpiRead() that can be reached only by resetting DVDD15 or low temperature
          bootLogEntry ((char *)fname, __LINE__, BOOT_SPI_LOG_READ_FAIL);
          *sizeBytes = 0;
          return (NULL);
      }

over 4 years ago

0 Mukul Bhatnagar over 4 years ago

TI__Guru* 78365 points

Hello Sato-san

It appears to me that the issue is still related to a previous post from your colleague?

If so , the observations and results with pulsing DVDD15 low and high seems appear to some what a distraction or may be leading you to the wrong debug path. It is important that you must do the power -> clock -> sequencing as required and only then you can debug the system properly.

We received some additional information from Sugawara san but the scope shorts are too small to read the voltage scales.
We find it concerning that you observe persistent voltage offsets after events that change the current draw – like taking the device out of reset. At a high level we expect that your power delivery solution should be either a) using local supplies with ‘remote sense’ that compensate for static IR drops or b) using common supplies delivered through lots of copper so that current changes do not result in persistent voltage reduction.

All supplies must be within the rated range at all times (even during droops and transients) and we do not expect any difference between board to board. There is likely some deficiency in the design that is hard to infer from the information shared so far.

0 Hidehito Sato over 4 years ago in reply to Mukul Bhatnagar

Prodigy 50 points

Hello Mr. Bhatnagar,

Thank you for your quick response. As you correctly guessed, my problem is related to the former post from my colleague.

We have checked many times that all the power and reset sequence are consistent with the description of the DSP's datasheet with enough margin even at transitive moments.

Today I discovered removing an external pull-up resistor from TIMI0 (port No.: AD20) eliminates the problem and DSP seems to correctly finish booting up.

We were aware the port was pulled down internally, but we wanted to use port AD20 as a GPIO after booting was done, thus we put external pull-up accordingly to our purpose.

Looking over the DSP's datasheet again, I found the following notes on page 190/236.

Also be aware that

systems using TIMI0 (the pin shared with PCIESSEN) as a clock input must assure that the clock is

disabled from the input until after reset is released and a control device is no longer driving that input.

Now I am wondering maybe DSP is taking high voltage on TIMI0 pin at booting as a clock input by mistake and this has been causing all the problem??

However, a part of sentence: "and a control device is no longer driving that input" seems to suggest TIMI0 port can be driven high/low externally before a clock is input. I am confused here.

Or is it possible that the tertiary function of AD20, which is PCIESSEN, is enabled at booting and that makes DSP suddenly switch to PCIe booting in the middle of SPI booting?

This theory might explain why temporarily pulling DVDD15 (used by PCIe blocks) low enables DSP to continue the rest of SPI booting.

Best regards,

Sato

TIMI0

0 Mukul Bhatnagar over 4 years ago in reply to Hidehito Sato

TI__Guru* 78365 points

Sato-san

I will need to discuss your TIMIO observation with the c665x datasheet expert - they are currently out till early next week.Is SPI boot failures the only issue between a good vs bad board?

I am assuming on a good board the TIMI0 external pull is not making any difference between pass and fail (that can happen as you may have c665x devices have process variation, and have different current consumption etc) to impact the pull up/pull down etc.

Regards

Mukul

0 Hidehito Sato over 4 years ago in reply to Mukul Bhatnagar

Prodigy 50 points

Hi Mukul,

> Is SPI boot failures the only issue between a good vs bad board?
So far, we have notice only this issue, but not quite sure if there is nothing wrong elsewhere.

For further analysis, we developed a system to externally pull TIMI0 port high or low at any precise moments.
Using this system, we confirmed that all bad boards which fail to SPI boot get to finish booting if TIMI0 is pulled low at the moment of the rising edge of RESEFTFULL.
TIMI0 needs to be pulled low only for (at most) 1ms before and after the rising edge of RESEFTFULL. TIMI0 can be pulled high for any other moments without affecting booting.
On the other hand, if TIMI0 is pulled high at the moment of the rising edge of RESEFTFULL it always fails booting even when RESEFTFULL is pulled low for other moments.

It is now clear SPI booting is quite dependent on the voltage of TIMI0 at the rising edge of RESEFTFULL.
Would you please check with an expert who has detailed knowledge of the internal circuits of these ports?
These two ports seem to be quite unrelated from the information of the datasheet, but the behavior of many bad boards unanimously tells us they have a strong dependency.

Best regards,

Sato

0 Mukul Bhatnagar over 4 years ago in reply to Hidehito Sato

TI__Guru* 78365 points

Hi Sato-san

Good to hear that you have done additional thorough testing to attribute this issue to TIMI0 pull.

I will update you early next week, if I am able to get additional guidance based on my discussion with datasheet expert on this (they were out of office this week).

Was this the only issue between good vs bad boards? Are all boards working as expected now? Please confirm

Regards

Mukul

0 Hidehito Sato over 4 years ago in reply to Mukul Bhatnagar

Prodigy 50 points

Hi Mukul,

Yes this is the only issue betweeen good vs bad boards. All bad boards succeed in SPI booting by pulling TIMI0 low.
Looking forward to hearing from you soon.

Best regards,
Sato

0 Mukul Bhatnagar over 4 years ago in reply to Hidehito Sato

TI__Guru* 78365 points

Hi Sato-san

I discussed this with the datasheet experts and your observations make sense

It is now clear SPI booting is quite dependent on the voltage of TIMI0 at the rising edge of RESEFTFULL. Would you please check with an expert who has detailed knowledge of the internal circuits of these ports? These two ports seem to be quite unrelated from the information of the datasheet, but the behavior of many bad boards unanimously tells us they have a strong dependency.

For C6652 the pin should be treated as reserved during boot process and should not be pulled up - by pulling it up, the ROM is assuming PCIESSEN is 1 and causing the unexpected behavior.

We can add more clearer guidance on how to treat AD20/reserved pin specifically for c6652 , in the datasheet as a corrective action.

Hope this helps.

Regards

Mukul

0 Hidehito Sato over 4 years ago in reply to Mukul Bhatnagar

Prodigy 50 points

Hi Mukul,

Thank you for confirming our observation.

> We can add more clearer guidance on how to treat AD20/reserved pin specifically for c6652, in the datasheet as a corrective action.

It is a big surprise c6652 without PCIe is assuming PCIESSEN is enabled at booting.
We also have boards with c6654 mounted instead of c6652. When TIMI0 port is pulled up, some of them fail SPI booting just like the boards with c6652. So we understand this problem is not specific to c6652 and happens on c6654 as well. Correct us if we are wrong.

We are going to re-design our board and remove the pull up from TIMI0 port, but we are now getting worried about other pins.
In order to be entirely reassured that we will not have to re-design our board again in the future, could you answer following questions?
We have no clue about these questions without knowing the mechanism of the problem and internal circuits.

Q1)
Actually, we have many boards with c6652 or c6654 that successfully boot from SPI flash without problem even though TIMI0 is pulled up while all other boards fail.
Why some boards succeed and all others fail with the exact same board design? What can make the difference?

Q2)
According to the datasheet, boot mode is solely determined by the voltage settings of BOOTMODE[12:0] pins at booting. Why can PCIESSEN interrupt the booting process then? Is it a hardware bug?

Q3)
Is PCIESSEN the only pin that can interrupt boot or normal operations of c6652/c6654?
For example PCIESSMODE[1:0] are strongly related with PCIESSEN. Is it safe to put pull up resistors on PCIESSMODE pins and use them as GPIOs?
Please let us know if there are other pins that might cause problems.

Best regards,
Sato

0 Rahul Prabhu over 4 years ago in reply to Hidehito Sato

TI__Guru** 114410 points

Sato-san,

The PCIESSEN pin is latched into the DEVSTAT register (bit 16) during boot. You may want to read the location 0x02620020 on the failing and the working boards to compare. This register is read by the bootROM to interpret the boot pins to configure the device and the boot peripheral.

The C6654/C6652 devices share the same boot ROM even if the PCIe peripheral is not supported on the lower power variants. PCIe should be powered up when the pciessen bit is set in devstat. When the PCIESSEN bit is set the boot ROM will enable the PSC for PCIe which we suspect is causing the behavior that you are reporting. Here is the ROM execution flow when the bit is set:

        i = ireadDevstatBits (DEVSTAT_BITS_PCIE_EN_MSB, DEVSTAT_BITS_PCIE_EN_LSB);

        if (i == DEVSTAT_FIELD_PCIE_ENABLED)  {
            v = chipForm32 (chipDefaultPcieDeviceId(), chipDefaultPcieVendorId());
            pscEnableModule (DEVICE_LPSC_MODNUM_PCI);
            hwPcieSetDevInfo (chipDefaultPcieClassCodeRevId(), v);
        }

PCIEMODE pins are only used if the boot mode is configured as pcie boot which will not impact SPI boot. For reference to check use of these pins, you can download the C665x ROM source from here:
http://software-dl.ti.com/sdoemb/sdoemb_public_sw/rbl/1_0_C6657/index_FDS.html

Let me discuss this internally with our HW expert and comment on your other questions. Can you also confirm that PCIECLK pin is static during the boot process and not left floating as indicated in the datasheet.

Regards,
Rahul

0 Mukul Bhatnagar over 4 years ago in reply to Hidehito Sato

TI__Guru* 78365 points

Hi Sato-san

>>So we understand this problem is not specific to c6652 and happens on c6654 as well. Correct us if we are wrong.

Given you are respinning the board, it will be good to confirm that the issue is truly related to ROM interpreting the boot to be PCIe boot etc. Rahul's suggestion in his previous post is good to understand this

You may want to read the location 0x02620020 on the failing and the working boards to compare. This register is read by the bootROM to interpret the boot pins to configure the device and the boot peripheral.

I also stay concerned about some of the differences in the voltage levels etc on good vs bad boards - as I previously mentioned that independent of this issue it will be good to make sure your power delivery network design is done correctly to ensure at all times the voltage levels are within datasheet spec.

Finally , since you are respinning your board, and are using both c6654/52 but not using PCIe, I would recommend looking at section 6.3.1 in the datasheet on unused clock pins

If a clock input is not used it must be held in a static state. To accomplish this the N leg should be pulled to ground through a 1 kΩ resistor. The P leg should be tied to CVDD to ensure it will not have any voltage present until CVDD is active. Connections to the I/O cells powered by DVDD18 and DVDD15 are not failsafe and should not be driven high before these voltages are active. Driving these I/O cells high before DVDD18 or DVDD15 are valid could cause damage to the devic

For your questions

Q1)
Actually, we have many boards with c6652 or c6654 that successfully boot from SPI flash without problem even though TIMI0 is pulled up while all other boards fail.
Why some boards succeed and all others fail with the exact same board design? What can make the difference?

[MB]

As recommended you should read DEVSTAT (location 0x02620020) on the failing and the working boards and compare. You had also previously described differences in behavior due to voltage and temperature and we think this is to do with device the leakage variation (device to device / board to board variation) of the internal pull resistor since you have a weak external pull resistor to the opposite polarity. It is important that are able to establish a correlation of success or failure based on the latched value.

Q2)
According to the datasheet, boot mode is solely determined by the voltage settings of BOOTMODE[12:0] pins at booting. Why can PCIESSEN interrupt the booting process then? Is it a hardware bug?

[MB] I don't see a hardware bug here. There is clear guidance on how this pin should be treated during reset etc. Let me know if I am missing anything here in terms of your concerns.

Q3)
Is PCIESSEN the only pin that can interrupt boot or normal operations of c6652/c6654?
For example PCIESSMODE[1:0] are strongly related with PCIESSEN. Is it safe to put pull up resistors on PCIESSMODE pins and use them as GPIOs?
Please let us know if there are other pins that might cause problems.

[MB] Not aware of any other pins impacting boot process.

Hope this helps.
Regards

Mukul

Processors

Processors forum

TMS320C6652: SPI booting gets suspended after the initial 4 bytes