[solved] Need help with RV901T as MESA 7i90: SPI isn't working

More
2 years 7 months ago #296756 by ago_tm
Looks like I get some progress with SPI, but there is only the understanding that SPI works good from RPi's side. The initial problem was in wrong analyzer customization (the falling edge of clock should be specified instead of rising edge).
(see the attachements)

I found in the code of mesaflash ( github.com/LinuxCNC/mesaflash/blob/master/spi_boards.c#L252 ) that it is expected to receive "MESA7I90"
I double checked the changes in i90_x9card.vhd for rv908t and ensured that parts of this word are on their places ( github.com/golyakoff/hostmot2-rv901t-7i9...2/i90_x9card.vhd#L76 ):
Code:
package i90_x9card is -- 7I90 x9 card specific info ... constant BoardNameLow : std_Logic_Vector(31 downto 0) := x"4153454D"; -- MESA; constant BoardNameHigh : std_Logic_Vector(31 downto 0) := x"30394937"; -- 7I90 ...

My understanding is that communication on SPI is working, as I see some response packets on MISO line, but it looks like the looped message:
Code:
Time [s], Packet ID, MOSI, MISO 0.0000030900, 0, STX(0x02), NUL(0x00) 0.0000035500, 0, NUL(0x00), DLE(0x10) 0.0000040150, 0, P(0x50), P(0x50) 0.0000044800, 0, (128)(0x80), (130)(0x82) 0.0000049400, 0, NUL(0x00), BS (0x08) 0.0000054050, 0, NUL(0x00), (SP)(0x20) 0.0000058650, 0, NUL(0x00), (129)(0x81) 0.0000063300, 0, NUL(0x00), EOT(0x04) 0.0000067900, 0, NUL(0x00), DLE(0x10) 0.0000072550, 0, NUL(0x00), @(0x40) 0.0000077200, 0, NUL(0x00), STX(0x02) 0.0000081800, 0, NUL(0x00), BS (0x08) 0.0000086450, 0, NUL(0x00), (SP)(0x20) 0.0000091050, 0, NUL(0x00), (129)(0x81) 0.0000095700, 0, NUL(0x00), EOT(0x04) 0.0000100300, 0, NUL(0x00), DLE(0x10) 0.0000104950, 0, NUL(0x00), @(0x40) 0.0000109600, 0, NUL(0x00), STX(0x02) 0.0000114200, 0, NUL(0x00), BS (0x08) 0.0000118850, 0, NUL(0x00), (SP)(0x20)

I understand that the problem is in the bitstream, but not sure how to start experiments there. Now at least I see "something" at MISO line, but not sure how to interpret this information.

Probably you could help with the next places I can look at...

Please Log in to join the conversation.

More
2 years 7 months ago #296768 by ago_tm
I found this instruction: wiki.linuxcnc.org/cgi-bin/wiki.pl?Editing_MESA_Bitfiles
Where it is saying that the default Xilinx ISE "Design Goals and Strategies" are not good enough, so I followed them.
I tried to follow the instructions below, but anyway I get a kind of time constraints error for SPIOUT (G6) (see attachment). Probably it is explained a kind of garbage there.
Here is the timing report:
Code:
Timing constraint: OFFSET = OUT 12 ns AFTER COMP "COM_SPICLK"; For more information, see Offset Out Analysis in the Timing Closure User Guide (UG612). 2 paths analyzed, 2 endpoints analyzed, 1 failing endpoint 1 timing error detected. Minimum allowable offset is 13.989ns. -------------------------------------------------------------------------------- Paths for end point COM_SPIOUT (G6.PAD), 1 path -------------------------------------------------------------------------------- Slack (slowest paths): -1.989ns (requirement - (clock arrival + clock path + data path + uncertainty)) Source: SPIRegOut_31 (FF) Destination: COM_SPIOUT (PAD) Source Clock: COM_SPICLK_BUFGP falling at 4.500ns Requirement: 12.000ns Data Path Delay: 5.579ns (Levels of Logic = 1) Clock Path Delay: 3.885ns (Levels of Logic = 2) Clock Uncertainty: 0.025ns Clock Uncertainty: 0.025ns ((TSJ^2 + TIJ^2)^1/2 + DJ) / 2 + PE Total System Jitter (TSJ): 0.050ns Total Input Jitter (TIJ): 0.000ns Discrete Jitter (DJ): 0.000ns Phase Error (PE): 0.000ns Maximum Clock Path at Slow Process Corner: COM_SPICLK to SPIRegOut_31 Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- H5.I Tiopi 1.547 COM_SPICLK COM_SPICLK COM_SPICLK_BUFGP/IBUFG ProtoComp74.IMUX.2 BUFGMUX_X3Y14.I0 net (fanout=1) 1.007 COM_SPICLK_BUFGP/IBUFG BUFGMUX_X3Y14.O Tgi0o 0.209 COM_SPICLK_BUFGP/BUFG COM_SPICLK_BUFGP/BUFG SLICE_X0Y54.CLK net (fanout=38) 1.122 COM_SPICLK_BUFGP ------------------------------------------------- --------------------------- Total 3.885ns (1.756ns logic, 2.129ns route) (45.2% logic, 54.8% route) Maximum Data Path at Slow Process Corner: SPIRegOut_31 to COM_SPIOUT Location Delay type Delay(ns) Physical Resource Logical Resource(s) ------------------------------------------------- ------------------- SLICE_X0Y54.BQ Tcko 0.476 SPIRegOut_31 SPIRegOut_31 G6.O net (fanout=2) 2.281 SPIRegOut_31 G6.PAD Tioop 2.822 COM_SPIOUT COM_SPIOUT_OBUF COM_SPIOUT ------------------------------------------------- --------------------------- Total 5.579ns (3.298ns logic, 2.281ns route) (59.1% logic, 40.9% route) --------------------------------------------------------------------------------

I saw somewhere that the good point for the experiments is to play around the SPI frequency on the bitstream. Please feel free to advise, thanks!

Please Log in to join the conversation.

More
2 years 7 months ago #296774 by PCW
The FPGA slave output looks bizarre (like a clock)
One way I can see this happening (assuming the pins are correct)
is that you have double clocking from SI issues

Do you have enough grounds between the cards?

Ground bumping is a huge issue here, for example, the 7C81 uses all 8 RPI grounds
and AC bypasses all unused power pins giving  a total of 12 HF ground returns to
avoid this issue.

Please Log in to join the conversation.

More
2 years 7 months ago #296792 by Cant do this anymore bye all
Did you change the values for he DCM sections to take into account the 25MHz clock ?

I just looked at my sources and notice that I had to change them as the 7i90 has a 50MHz clock and the rv901t has a 25Mhz clock.

I had to do the same, but the other way, when I used the Spartan dev board as that has a 100MHz clock.

Please Log in to join the conversation.

More
2 years 7 months ago #296793 by ago_tm

The FPGA slave output looks bizarre (like a clock)
One way I can see this happening (assuming the pins are correct)
is that you have double clocking from SI issues.

Do you have enough grounds between the cards?

Ground bumping is a huge issue here, for example, the 7C81 uses all 8 RPI grounds
and AC bypasses all unused power pins giving  a total of 12 HF ground returns to
avoid this issue.

Thanks, yes, the next step is to check the SPI clock — looks like I missed this:
forum.linuxcnc.org/27-driver-boards/4182...-on-dev-board#201885 .

About the common ground - I used the only wire, I will also try to improve this. Thanks!

Please Log in to join the conversation.

More
2 years 7 months ago #296830 by ago_tm
I did the changes related to the difference of crystal oscillator (25MHz instead of 50MHz in original 7i90):  github.com/golyakoff/hostmot2-rv901t-7i9...64f0c39f21bfd875f86c
But the result is the same: I still receive a kind of garbage bytes in MISO line, for example:
Code:
Time [s],     Packet ID,    MOSI,     MISO 0.0000028250,     0,    STX(0x02),    NUL(0x00) 0.0000032850,     0,    NUL(0x00),    NUL(0x00) 0.0000037500,     0,    P(0x50),    P(0x50) 0.0000042150,     0,    (128)(0x80),    (130)(0x82) 0.0000046750,     0,    NUL(0x00),    BS (0x08) 0.0000051400,     0,    NUL(0x00),    (SP)(0x20) 0.0000056000,     0,    NUL(0x00),    (129)(0x81) 0.0000060650,     0,    NUL(0x00),    EOT(0x04) 0.0000065250,     0,    NUL(0x00),    DLE(0x10) 0.0000069900,     0,    NUL(0x00),    @(0x40) 0.0000074550,     0,    NUL(0x00),    STX(0x02) 0.0000079150,     0,    NUL(0x00),    BS (0x08) 0.0000083800,     0,    NUL(0x00),    (SP)(0x20) 0.0000088400,     0,    NUL(0x00),    (129)(0x81) 0.0000093050,     0,    NUL(0x00),    NUL(0x00) 0.0000097650,     0,    NUL(0x00),    DLE(0x10) 0.0000102300,     0,    NUL(0x00),    @(0x40) 0.0000106950,     0,    NUL(0x00),    STX(0x02) 0.0000111550,     0,    NUL(0x00),    BS (0x08) 0.0000116200,     0,    NUL(0x00),    (SP)(0x20)
and bytes randomly differ each time.

I have no more ideas at this point...
What is the speed of SPI clock should be in the original 7i90? My is ~20 MHz...

Please Log in to join the conversation.

More
2 years 7 months ago #296833 by PCW
Did you fix the grounding?.

I would expect that kind of behaviour with only one ground wire.

SI issues like this will not be solved by lower clock speeds
if you do not get one bit shifted out for each clock, you have a SI issue...

Please Log in to join the conversation.

More
2 years 7 months ago #296837 by ago_tm
Hello sir,

Did you fix the grounding?.

I would expect that kind of behaviour with only one ground wire.

Yes, I added 3 more wires to the different corners of the board (see the attachment).
Not sure what is the result I get - the MISO line became without any noise - now it always 0x00 (straight line 3v3). Looks like the "garbage data" was just a noise... At least it become correlate to the message:
Code:
Unexpected cookie at 0100..0110: 00000000 00000000 00000000

SI issues like this will not be solved by lower clock speeds
if you do not get one bit shifted out for each clock, you have a SI issue...

Understand about the frequency. But I what you are meaning under "SI issues"? And how can I get one bit shifted? Could you kindly explain?

Please Log in to join the conversation.

More
2 years 7 months ago #296841 by PCW
SI stands for Signal Integrity

Note that adding the logic analyser
(if it does not have resistors in the actual probe clips)
will cause major SI issues by itself

You might try with the LA disconnected
Another possibility is adding a series termination
resistor to the clock line source end (say 47 Ohm)

Please Log in to join the conversation.

More
2 years 7 months ago #296846 by ago_tm

Did you change the values for he DCM sections to take into account the 25MHz clock ?

I just looked at my sources...

Hello cornholio,

I would be grateful if you could share your sources for 7i81. I will try to compare with the original to doublecheck the places I have changed already.

Please Log in to join the conversation.

Time to create page: 0.083 seconds
Powered by Kunena Forum