XS1-L4A-64 SPI boot / boot mode problems

[fox]

Hi,
 
we are currently having some issues with booting from Flash on our custom design XS1-L4A board (relevant parts of the schematics are attached, all ports are used, I just removed anything that's not related to the problem).
 
The symptoms are, that the XMOS doesn't try to boot from SPI-Flash _most_ of the time, meaning 1 out of 20 boots (via complete power cycle) work, the others show no activity on the SPI lines to the flash. The XMOS seems to catch an exception in ROM code in those situations:
 

Code: Select all

$ ​xrun --dump-state-no-xexrun: Program received signal ET_ECALL, Application exception.      0xffffc174 in ?? ()      ***** Active Cores *****      * 1  tile[0] core[0]  0xffffc174 in ?? ()      Thread 1 (tile[0] core[0]):      ***** Call Stack *****      #0  0xffffc174 in ?? ()      ***** Disassembly *****      0xffffc174:       ecallt (1r)     r10      0xffffc176:       setc (ru6)      res[r0], 0x0 *      0xffffc178:       setc (ru6)      res[r1], 0x0 *      0xffffc17a:       setc (ru6)      res[r2], 0x0 *      0xffffc17c:       bu (lu6)        -0x53      ***** Registers *****      r0             0x200100   2097408      r1             0x100200   1049088      r2             0x100300   1049344      r3             0x2        2      r4             0xffffffff -1      r5             0x0        0      r6             0x0        0      r7             0x0        0      r8             0x10000    65536      r9             0xedb88320 -306674912      r10            0x9add2096 -1696784234      r11            0x0        0      cp             0x0        0      dp             0xffffc344 -15548      sp             0x0        0      lr             0xffffc164 -16028      pc             0xffffc174 -16012      sr             0x51       81      spc            0xffffc174 -16012      ssr            0x0        0      et             0x8        8      ed             0x0        0      sed            0x0        0      kep            0xffffc300 -15616      ksp            0xffffc300 -15616

A simple reset on the running system (via RST_N assertion) does not resolve the problem. Is there a way to see the MODE pin states in this situation?
 
Restarting the NCP1521 1V (U10) supply while the rest of the system stays powered by shortly pulling the EN to ground does sometimes work.
 
It seems _not_ to work when the GND level is applied and released cleanly from the EN pin.
On the other hand, it does seem to work when there are some glitches on the 1V output, because (one or more spikes down, GND level is applied via hand, and therefore not debounced).
 
 
The original design doesn't use the first RESET circuit (left U11) and was basically the same as on the various devkits, we added it to play with different hold-off times for the 1V supply. This didn't work, infact if we configured the left NCP303... to assert it's output for 0.5 seconds we never managed to boot the XMOS again.
 
All power levels and the switch-on timing look fine on the scope.
 
 
We tried:

1. To pull the MODE 2+3 pins high with additional pull-ups (no effect)
2. Use 10 ms up to 500 ms resets for both U11 (shorter timings worked more ofter, but that's probably caused by the power-on bounces)
3. Power-On without the first U11, the 1V supply is enabled when 3V3 is ready. (no effect)
4. Manually playing around with the RST_N, holding RST_N down manually and then releasing it when everything is stable had no effect. Asserting RST_N in the faulty state had no effect.
5. Connecting the XTAG-2 to the debug connector had no effect in itself. But the XTAG-2 was always able to reset the device, reflash it or run a program via JTAG when it didn't start correctly.

 
We are currently pretty much out of ideas of what to try next. Any input would be appreciated!
 
Is there any more info on POR reset timing requirements. Are there any restrictions besides the "VDDIO must reach 3.3V before VDD reaches 0.4V" for the supply voltages? Is there a complete timing diagram for the 3.3V, 1V, RST_N, TRST_N, MODEx lines for a successful POR?
 
 
Thanks in advance
Björn

[mon2]

How are you generating the +3.3 volt rail for this product ? What are the details of the +3.3 volt regulator ? In following the XK-1 reference design schematic which appears to be similar to your design, each of the downstream regulators are sourcing their voltage from the main +5 volt rail so as to not load down the previous (upstream) regulator.

You noted that for Mode 2 & Mode 3, you applied pull-ups to force SPI EEprom boot (which would sound logical) but in the XK-1 kit, the pull-ups are not externally applied. Test without XTAG connected and leave Mode 2 & Mode 3 pins floating as to default to "11" with their internal PU (confirmed with XS1-L4 datasheet that each Mode pin contains an internal PU). The datasheet for the XS1-L device states to not use a PU to VDDIO which is interesting (section G.2).

How far is the SPI EEprom from the XMOS device ? We are beating this subject to death but we had a very rough time in working with the Winbond SPI devices during our Quad SPI review last year. The root cause was related to long logic analyzer leads (unshielded) which then we replaced with shielded and the results improved. However, under the same nasty lab setup which could not be avoided, we replaced with Spansion and all worked well using Quad SPI transactions. The boot rom in the XMOS devices is using standard SPI commands which are quite a bit slower so technically should be tolerant of longer trace lengths. Now, Winbond does offer newer generation of designs of their flash which feature a stronger pin drive but as noted, Spansion worked where Winbond did not under the same test conditions with the rather long cable lengths for the Quad SPI code development.

Consider to take a known working piece of code (blink an LED) - verify the SPI flash to be stable on an XK-1 (example) and then replace with the same flash device onto this board to see if you can replicate the same success. This substitution will rule out the specific flash component out of this equation. At this time of writing, we have more faith in Spansion flash devices but if you are not seeing activity on each power up cycle / reset on the SPI lines from the XMOS master state machine then the issue is elsewhere.

You have an open drain buffer (dual 74HC07 series) with a 47k on input and 47k on output. Technically to compare agains the XK-1 design, their 74HC07 features a 47K PU but then follows a NC7WZ17 ( DUAL UHS BUFFER WITH SCHMITT TRIGGER INPUTS ) which will drive the pins high (vs open drain) and low which would prevent you from using XTAG - although the XK-1 features this device(?). Perhaps worth considering to apply the same if the above do not resolve the issue. Conside to change the input & output PU resistors from 47k to 10k or stronger if you leave the 07 open drain buffer in place.

How many layers is your PCB ? 4L or 2L ? Layout is EMI clean ? You are using the SiLabs MEMs oscillator and historically their devices have been solid with us (we have used their digital isolators for years) but you could consider to try perhaps a lower speed standard crystal oscillator.

The above comments are supplied in order of possible issues but assuming that your not shown portions of the design are not responsible for the faults. That is, some pre-bias condition on the other IO pins is causing the boot up issues. Hope you can work it out soon.