XHRA QSPI flash booting problem

[mon2]

Most likely the root cause will be the voltage supervisor.

Aside from fixing the PCB layout, consider to source a few pieces of the TO-92 footprint leaded voltage supervisor (Microchip ?) and solder onto the same 3 pads with the proper pin mapping.

Moving forward you should be able to source parts with built in PG outputs (power good) from suppliers like Richtek (do confirm if the current draw is suitable for the respective LDO).

Where possible and space permitting, allow for 'dual footprint' parts so that you can flip on a dime during production shortages and also to keep the vendors competitive against each other. For example ADM1085 is a pricey part and you should be able to cost reduce here with an alternative.

For low cost switchers, there is ROHM. Since you are dropping from 5V0 down to 3V3, there are many such suppliers out there.

For ESD protection devices at low cost, consider SOCAY (Shenzhen, China). We use them all the time and they are the true manufacturer for the big boys. BTW - you should not need to worry about ESD protection between the XMOS and the QSPI device unless the flash device is exposed to the outside in some fashion. So TVX2 is most likely not serving its purpose on this design.

ESD and surge protection on the USB rails is recommended. Strong connector board locks (through hole are best) are recommended for the USB connector to avoid trace rips = RMA of the end product.

SW4 - needs attention as this is a mechanical push button for the #RST line. This will lead to lots of signal bouncing on that line (since it is a mechanical PB with springy contacts). There are assorted low cost switch debouncers you can use here like (random selection from the net):

https://www.maximintegrated.com/en/app- ... vp/id/1858

The mechanical PB must generate a clean and single output pulse when pressed to properly reset the XMOS device.

Hope it all works out for you. Keep us posted.

[wlodek]

Hi guys,
Thank you very much for your great help.

We have fixed the voltage supervisor STM1061 wiring. When measured on the scpe, the reset on the XHRA goes HIGH after approx 11 ms after 3.3 V supply - which is enough for having stable 24 MHz on the output of the PLL.
Still our board does not boot properly. The SCK clock from XHRA to QSPI flah is 10 MHz (against 2.5 MHz on the evaluation board). EBh fast read is issued to the flash but the CE# never goes back HIGH and SCK signal is ticking.
I will remove the QSPI flash from our board and replace it by the flash from from EVB to be sure that this is not the problem. The contents of the QSPI flash on o our board was generated by the XMOS configuration utility from the cfg file that was attached to the EVAL board. We just cleaned all events ant left the INIT event only which should toggle the LEDS.

Do you have any idea what makes 2 XHRA controllers with the same revision produce different SCK from the same 24 MHz input clock?

Cheers,
Wlodek

[mon2]

Post the measured values for:

XMOS EVB:

CLK0 (pin 10) of the PLL
CLK1 (pin 9) of the PLL
CLK2 (pin 6) of the PLL

Your PCB:

CLK0 (pin 10) of the PLL
CLK1 (pin 9) of the PLL
CLK2 (pin 6) of the PLL

Concern is related to this found document:

http://www.silabs.com/internal-apps-man ... dendum.pdf

Is the sourced factory programmed PLL generating the matching clock values as found on the XMOS EVB for each CLKx pin ?

[wlodek]

Hi

XMOS EVB:

CLK0 (pin 10) of the PLL 24 Mhz
CLK1 (pin 9) of the PLL 24 MHz
CLK2 (pin 6) of the PLL 6 Mhz

My PCB:

CLK0 (pin 10) of the PLL 49 MHz
CLK1 (pin 9) of the PLL 24 MHz
CLK2 (pin 6) of the PLL 45 MHz

CLK0 and CLK2 on my board seem to be not changed from Si5351 defaults and this is clear because my QSPI flash does not specify any event to reprogram these frequencies and what is more probbable the XHRA on my board does not boot properly.

[mon2]

Remove the PLL from the XMOS EVB and place onto your PCB to confirm if the XMOS supplied PLL is able to make your PCB function correctly - especially the QSPI clock @ 2.5 Mhz.

Perhaps the QSPI clock is derived from CLK0 or CLK2 inputs ? No idea on this but it is a thought.

[wlodek]

We have already done it before. The PLL on my board is already taken from the EVB. We then solderd a new PLL to the EVB.
I think that the QSPI clock can not be derived from the CLK0 or CLK2 as these two clocks are normally reprogrammed only after XHRA is booted and this is done from the QSPI.

What comes to my mind now is to take the XMOS XHRA from the EVB and put it on my board to see if it will start with 2.5MHz (which would say that firmawares are different on these two XHRAs)

[henk]

Hi,

Just a thought - I noticed you have zero-ohm resistors on the PLL - how long are the traces to the XHRA device, and how are they separated from the other clock?

In particular - would echoes or cross talk be a problem on the 24 MHz clock?

Cheers,
Henk

[wlodek]

Hi,
Clock traces are rather short (1 cm +/-). We put 0 Ohm just in case we had problem in EMC chamber and if we have to temper the slopes.
Traces are separated more than pins.

[mon2]

Perhaps losing track of all of the ideas you have tested but it is sounding like the firmware may be different inside the XMOS devices.

However, even at 10 Mhz, the QSPI clock is not beyond the spec of the respective flash device.

Does the XMOS EVB flash on your board still continue to clock the QSPI CLK @ 10 Mhz ? That is, if you remove the XMOS EVB original flash (2.5 Mhz if on the EVB) -> solder onto your PCB, the QSPI clock escalates to 10 Mhz ?

You could try to inject your basic LED flasher code inside a different brand like Spansion which we recall having some great results on high speed transfers. But as noted, 10 Mhz is still relatively slow for these flash devices. Winbond was the other brand we tested but take note that there are so many ordering options from Winbond.

So your SPI flash, if soldered onto the XMOS EVB, will clock @ 2.5 Mhz upon power up ? If yes, our vote is that the XMOS firmware is truly different inside the CPU. On this topic, does the XMOS EVB with your LED flasher firmware proceed to blink / toggle the respective GPIO pin ? This would confirm that your firmware inside your SPI flash device is properly formatted and being fetched ok in QUAD SPI mode. This will be an excellent test to allow you to move forward to do the same using a SPANSION brand flash device.

Summary: try to blink the LED using your firmware but solder onto the XMOS EVB - if LED blinks as expected -> move to repeat using the SPANSION brand of flash memory and confirm again on the XMOS EVB -> working ? Yes, then test on your board (even @ 10 Mhz) - should still continue to flash.

In the meantime, will try to hunt down the same XMOS board for some testing. We have a QUAD SPI bus analyzer. It is possible the firmwares are different but as noted, even at 10 Mhz, cannot see an issue with the clock speeds. From memory (no pun), recall we were testing at 20 to 25 Mhz QSPI clock speeds in the lab.

Focus on the LED blink code using your flash on either one of these boards to raise the confidence levels.

You almost need an exorcist for this board but it will be nice and logical when it all works correctly.

[wlodek]

Hi,
We will exchange XHRAS between EVB and our board. I am a little afraid of doing this because we have only one EVB left.
I think that 10 MHz should not be a problem for QSPI flash but may be it is a problem for XHRA.

We will also exchange flashes but I can not imagine how the flash could influence the SCK QSPI frequency of the XHRA (we keep measuring 24 MHz on the input to XHRA - this does not change).

It is worth to try with another XHRA on our board - maybe XHRA is slightly damaged?

The QSPI flash seems to be OK. We do not have QSPI analyser but we managed to see firs data comming from QSPI and it was (as far as we could decode it) D3h 70h - eaxctly as we see in buffer of our flash programmer.