Debugging SPI Boot

[Folknology]

I am assuming you have read the link guide

Crosstalk and Noise

Because xCONNECT Links are a transition-based protocol rather than a level-based protocol, they are vulnerable to noise via crosstalk or EMI. Accordingly xCONNECT Links should be designed to minimize noise:
Do not route the signals closely in parallel for large distances. The traces need separating out to minimize cross-talk between the lines.
Do not route the signals close to noisy items on the PCB (such as switch-mode power supplies and clocks).
Try not to route the xCONNECT Link over splits in the ground plane, as the return ground currents can cause cross-talk.
If the traces are going over long distances, use low voltage differential signalling transceivers (LVDS) at each of the link to make the links immune to common-mode interference and improve the achievable symbol rate be utilized.

Pulldown Resistors

When xCONNECT Links are enabled, the wires should be logic low. Weak internal pull downs are active on the xCONNECT Link pins before they are enabled. These pull downs cannot be relied upon to pull down long traces with high capacitance. Circuit designers should apply external pull down resistors on such tracks.

And your deployment scenario (I think)

5w and 2w Link with up to 100mm of PCB Track
Link with 33R series terminating resistors close to the TX sides of each wire, using no driver chips.

But I'm probably preaching to the choir here.

regards
Al

[segher]

Let's assume then your links work Just Fine at 6/6.

Have any routines to change the link speed from an application? Not sure if you just go ahead and write the bits in registers 0x80-0x87 on the node configuration, or not?

I think you'll need to reset the links as well, send HELLO etc.

I am also unclear as to what switch is which XLINK?

All links are on the sswitch. 0 to 3 are C,D,A,B.


It seems you still have a timing issue in the startup code.
Do you have xrun etc. dumps from when it fails?

[bearcat]

I am going to do more testing on this over the next couple days. I want to re-run an XLINK test at different speeds to see if there are errors on the link and what speed, if any. I believe it still has boot problems maybe 1 out of 10 times. I did switch to closer to 500MHz, so maybe the PLL is not quite fast enough at that setting.

I also need to nail down more accurately the speed I need for the application on the XLINK, which is used for the USB link, and I haven't had enough testing there.

I am also back to XDE 11.11.1 (it does boot now). The latest XUD in my application is not quite right yet after more testing. Also, the debugger doesn't work for me in V12 or V13, so V11 it is for now.

I will re-post the xlreg and boot results later....

[segher]

I am going to do more testing on this over the next couple days. I want to re-run an XLINK test at different speeds to see if there are errors on the link and what speed, if any.

Great, data is good! Well better than guesswork anyway ;-)

I believe it still has boot problems maybe 1 out of 10 times. I did switch to closer to 500MHz, so maybe the PLL is not quite fast enough at that setting.

Another option is 500.736MHz, which has a nice small ratio.
Technically that's overclocking of course.

I will re-post the xlreg and boot results later....

Good luck, and don't forget to have fun!

[bearcat]

I had tried a little overclock, and it boots also. The following were ran using 499712000Hz and booted from flash with no XTAG2 connected.

So, back to the problem at hand. Using 11.11.1, the slim/dfu code boots, it appears 11.11.1 is not concerned with XLINK delay. It boots from flash at even delay 1,1! I ran the "test" below at delay1 for 2 minutes without any errors. A couple million words back and forth.

I ran a "test" overnight at delay 4,4, and got the following results:

V5 11.11.1 Delay4 test.JPG

No errors. Thats over a billion sends and receives without errors. When I did short two of the XLINKS pins with a screwdriver the program stopped, from a resource exception probably, so the test is doing what I wanted.

So, I have to believe the XLINK on my hardware is quite robust (and a great design by XMOS), and capable of running at least delay4, and shown to run delay1. Why version 13 won't boot below delay 10 is unknown.

Here's the test code snippet I used. 4 times a loop, 48K loops a second. TESTVALUE was (0x59C30F1D)

Code: Select all

            outuint(c_factory, TESTVALUE);
            temp = 0;
            temp = inuint(c_factory);
            if(temp != TESTVALUE)
            {
            	xlinkerrfac++;
    			lcdwrite(-17);
            	lcdwritenumber(xlinkerrfac, 7);
            }

So I will be continuing with version 11.11.1, and see what happens. Inlining works for me in 11.11.1 also.

I'm having fun again, now it's booting from flash, and the debugger works.

[richard]

You mean you have an acceptable workaround ;-) But I bet
Richard will want to solve it for everyone once and for all :-)

Definitely - we will review the delays xflash uses during the boot process - they are clearly too short in some cases.

Why version 13 won't boot below delay 10 is unknown

I suspect this is again related to insufficent delays in xflash. If the links are going slower then you might not hit the same race conditions.

[segher]

That is excellent news!

Wow, 1,1 works? How fast is that?

I don't see what's special about 59c30f1d. I'll be terribly
disappointed if you just picked a random number -- I want
to have fun as well!

[bearcat]

100Mhz is pretty good. Shows the XLINK protocol is pretty robust. The waveforms looks terrible, but my scope is only 50MHz and the probes are probably worse. I still plan on running more like delay 6,6.

That number is an approximation of the orbital circumference of mars in kilometers.