TMS320C5517: On the dispersion of SPI Flash Boot start time

Hi,

I've notified the factory team. They will post their feedback directly here.

Best Regards,
Yordan

Hi H.U-san,

What SPI pins are being used (ball numbers)? What is the boot mode at reset (BootMode[5:0])? Are the internal LDOs being used to supply core voltages?

I have observed varying boot times on C55xx devices that depend on the charge remaining in the BG_CAP.

Does the boot time decrease (boot faster) if the power is switched off for a short amount of time and then quickly switched back on?

As an experiment, I fully discharged the BG_CAP capacitor with a wire to GND. This yielded the slowest boot times on the C5517 EVM.
Instead, if I switch the power off for 20 seconds and then turn power back on, I get a slightly faster boot time.
If I switch off power then quickly switch it back on, the boot time is faster by 20 to 30ms.
And if I keep power applied, but press reset, then the boot is fastest because BG_CAP is already charged.

Can you ask the customer to reproduce these tests so see if the boot time is dependent on the charge remaining in BG_CAP?

The bandgap capacitor (BG_CAP, 0.1uF) is charged with an internal resistance of approximately 320 kOhms. But if the bandgap cap does not fully discharge between power cycles, then it will charge back up faster. These parameters can vary with temperature.

Although outside of the datasheet recommendation, some customers have replaced the 0.1uF BG_CAP with a 0.01uF capacitor so it charges faster. I cannot recommend it for production, but it might be an interesting experiment to see if the boot time variability reduces.

If not, we can look for other sources of the variability in boot time (like oscillator startup time, CLKIN frequency, etc.)

Hope this helps,
Mark

Hi Mark-san,

Thank you for your reply.

Mark Mckeown said:

What SPI pins are being used (ball numbers)?

SPI_CLK : N3

SPI_CS0 : P4

SPI_RX : P6

Mark Mckeown said:

What is the boot mode at reset (BootMode[5:0])?

 BootMode[5:4] =  01      (12.288MHz)
 BootMode[3:0] =  0110  (SPI BOOT)

Mark Mckeown said:

Are the internal LDOs being used to supply core voltages?

No, the core power supply is driven by an external power supply

Mark Mckeown said:

Can you ask the customer to reproduce these tests so see if the boot time is dependent on the charge remaining in BG_CAP?

Power has been turned on after a sufficient time. and It is reset out immediately after the power supply ramps up.
Although the device is started under the same condition even in a low temperature environment, the SPI clock output timing is delayed.

So, Could you investigate factors other than BG_CAP?

Best regards,
H.U

Hi H.U-san,

Refer to this similar post on varying start-up times - e2e.ti.com/.../216426

How is DSP_LDO_EN connected on this board? If tied low, then the internal reset will be asserted. If high then the sole source of reset is the external reset pin. I understand CVDD is supplied externally, but I would like to know if the DSP_LDO is still enabled (DSP_LDO_EN tied low).

Temperature could also affect the crystal oscillator start-up time. Do they use a crystal to clock the device? If so, can they probe the crystal output at power-on time to see if there are differences in the ramp rate of the amplitude (would be best to use an active probe if possible).

I am still interested in the BG_CAP charging rate. Perhaps the internal resistor behaves differently at cold temperatures (its not really a resistor in silicon). If they were able to compare the BG_CAP charge times on a board in cold temperature verses a board at room temperature, that may show a meaningful difference.

The bootloader executes synchronously with SYSCLK. It should always take the same number of clock cycles once it starts executing. So we are looking for something analog that occurs before the bootloader begins executing - like reset, bandgap charging, clock activation, voltage ramp, etc.

Does the delay from RESET to SPI_CLK start scale with temperature? Or does it scale with time that the board has been turned off?

Regards,
Mark

Hi Mark-san,

Mark Mckeown said:

Refer to this similar post on varying start-up times - e2e.ti.com/.../216426

I could not access the link. The following message was displayed.

"Access Denied (Note: a common reason this message is displayed is because the thread was deleted)"

Mark Mckeown said:

How is DSP_LDO_EN connected on this board? If tied low, then the internal reset will be asserted. If high then the sole source of reset is the external reset pin. I understand CVDD is supplied externally, but I would like to know if the DSP_LDO is still enabled (DSP_LDO_EN tied low).

DSP_LDO_EN tied high.

Mark Mckeown said:

Temperature could also affect the crystal oscillator start-up time. Do they use a crystal to clock the device? If so, can they probe the crystal output at power-on time to see if there are differences in the ramp rate of the amplitude (would be best to use an active probe if possible).

I am still interested in the BG_CAP charging rate. Perhaps the internal resistor behaves differently at cold temperatures (its not really a resistor in silicon). If they were able to compare the BG_CAP charge times on a board in cold temperature verses a board at room temperature, that may show a meaningful difference.

There was no difference in the signal quality of the input clock. and they measured the charging time of BG_CAP at room temperature and low temperature, however no difference was found.
The customer swapped the C5517 chips mounted on normal board and not one, It is known that this issue depends on C5517.

Mark Mckeown said:

Does the delay from RESET to SPI_CLK start scale with temperature? Or does it scale with time that the board has been turned off?

They are measuring after a sufficient time has elapsed after turning off the board in each environment of room temperature and cold temperature.

Best regards,
H.U

Hi Mark-san,

Please let me know the current status regarding the issue.
My customer is in a big hurry for this issue. I need your support. 

Best regards,
H.U

Hi H.U-san,

I am very sorry for the delay in this response. We're running out of ideas to explain the difference in delay from RESET to SPI_CLK activity.

What is the state of the CLK_SEL pin?
If CLK_SEL is 0 at reset, the USB LDO is enabled, the USB oscillator is enabled, and the USB oscillator is used as the clock source for the system clock generator.
If this is the case, I would like to know if the USB_LDO is used to supply USB_ VDD1P3 and USB_VDDA1P3. USB_LDO can be slow to ramp (it ramps with the bandgap and BG_CAP).
And they should probe the USB oscillator in both cold and room temperature conditions to see if there is any difference.

Does the customer have access to the SPI_CLK pin when EBSR PPMODE = MODE5?
It is ball N10 I2S2_CLK/UHPI_HD[8]/GP[18]/SPI_CLK

The bootloader first tries to boot from SPI with this pin muxing before trying with the pin mux that the customer is using. I want to know if you see a difference in the start time and duration of this SPI CLK in cold temperature and room temperature.

Do they have access to the CLKOUT pin also? I would like them to compare the time from RESET to a clock appearing on the CLKOUT pin and when the clock stops on the CLKOUT pin. One of the earliest steps in the bootloader is to disable the CLKOUT pin (right after TRIM), so it is a good status of when the bootloader has begun.

Did the customer attempt to replace the BG_CAP with the smaller 0.01uF capacitor? What were the results of that experiment?

Hope this helps,
Mark

Hi Mark-san,

Mark Mckeown said:

What is the state of the CLK_SEL pin?
If CLK_SEL is 0 at reset, the USB LDO is enabled, the USB oscillator is enabled, and the USB oscillator is used as the clock source for the system clock generator.
If this is the case, I would like to know if the USB_LDO is used to supply USB_ VDD1P3 and USB_VDDA1P3. USB_LDO can be slow to ramp (it ramps with the bandgap and BG_CAP).
And they should probe the USB oscillator in both cold and room temperature conditions to see if there is any difference.

CLK_SEL is 1 at reset.

Mark Mckeown said:

Does the customer have access to the SPI_CLK pin when EBSR PPMODE = MODE5?
It is ball N10 I2S2_CLK/UHPI_HD[8]/GP[18]/SPI_CLK

The bootloader first tries to boot from SPI with this pin muxing before trying with the pin mux that the customer is using. I want to know if you see a difference in the start time and duration of this SPI CLK in cold temperature and room temperature.

The customer checked the N10 pin at boot, but the signal was not output.
Does it need to change BootMode [3: 0] pin etc in order to output SPI clock from N10?

Mark Mckeown said:

Do they have access to the CLKOUT pin also? I would like them to compare the time from RESET to a clock appearing on the CLKOUT pin and when the clock stops on the CLKOUT pin. One of the earliest steps in the bootloader is to disable the CLKOUT pin (right after TRIM), so it is a good status of when the bootloader has begun.

No, unfortunately their board does not have the CLOKOUT pin on the board.

Mark Mckeown said:

Did the customer attempt to replace the BG_CAP with the smaller 0.01uF capacitor? What were the results of that experiment?

They experimented with the 0.01uF capacitor, although the ramp-up of the BG_CAP line became faster, the SPI clock output delay occurred in the low temperature. It seems that the delay time of SPI clock output is almost the same as 0.1uF.

Hope this helps,
Mark

Hi Mark-san,

Please let me know the current status regarding this issue.
As the result of our previous verification, we think that it is not a problem caused by the our H/W design.
If there are other concerns about H/W design, please point out.

Best regards,
H.U

Hi H.U-san,

Sorry again for the slow response.

Please let me confirm: Some boards experience a delayed boot when in cold temperature (but never at room temperature). And other boards have a delayed boot when at room temperature, but not in cold temperatures. Is this correct?

What abount of boards does this issue affect? How repeatability is the delay on these boards?
What are the bounds of the delay? Is the delay always 100ms or is it sometimes different?

To recap, I asked if the bandgap charge time was different when the delay is observed, but it is not.
I asked if the crystasl oscillator start up time was different when the delay is observed, but there is no differnece. I would like to know how you performed this measurement since the capacitace of a passive probe can affect the oscillator.

They experiment with the 0.01uF BG_CAP value, and observed an improvement in the boot speed, but still observed the delay during boot on the affected boards, correct?

Without knowing the state of CLKOUT, I'm leaning towards the idea that the delay occurs after the bootloader has started executing. So I traced through the bootloader source code looking for any source of a delay, like a polling while loop without any timeout. I found a two such loops in the eFuse copy section early in the bootloader execution. During this section, the CLKOUT pin toggles and afterwards it stops.

Observing CLKOUT would be of significant assistance to root cause this issue.
If the delay occurs 100ms before CLKOUT toggles, then the delay is occuring before the bootloader begins.
If CLKOUT toggles during the delay, then the issue could be the trim copy from eFuses. There are two polling loops without timeouts in that process.
If 100ms delay is after CLKOUT toggles, then its something software related in the bootloader (like maybe SPI_RX pin receives 0x09AA or other valid boot code)
The CLKOUT ball (A7) is on the outer perimeter of the BGA package. Is it possible to sneak a probe or piece of mag-wire to the ball to probe this signal?

Regarding the N10 I2S2_CLK not toggling... In mode 0b0110, the bootloader attempts to boot via SPI from EBSR PPMODE 5 before trying PPMODE 6. In PPMODE 5, you should have observed a SPI_CLK out of the N10 I2S2_CLK/UHPI_HD[8]/GP[18]/SPI_CLK ball, though typically just for a few clock cycles. In PPMODE 6, the SPI clock appears on the N3 SPI_CLK/UHPI_HINT ball). Can the customer probe this pin again to see if the delay occurs while the PPMODE 5 SPI_CLK is toggling? I will aslo probe my EVM to verify.

Another oddball question... Is there any toggling signal connected the N11 I2S2_RX/UHPI_HD[10]/GP[20]/SPI_RX during the boot process?

We need to isolate the section of the bootloader where the additonal delay occurs in order to root cause it.

Regards,
Mark

H.U-san,

Wonderful. Thanks for letting us know the resolution.

I will make sure next time to ask about the bootmode that has been latched much earlier in the debug sequence.

Regards,
Mark