Forum Menu

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

More
2 years 7 months ago #296684 by Cant do this anymore bye all
Replied by Cant do this anymore bye all on topic Need help with RV901T as MESA 7i90: SPI isn't working
And those reasons would be ?
Based on what ideas ?

Please Log in or Create an account to join the conversation.

More
2 years 7 months ago - 2 years 7 months ago #296688 by ago_tm
Replied by ago_tm on topic Need help with RV901T as MESA 7i90: SPI isn't working

Old mate is right, it'll work fine using the standard SPI pinout on the RPi4 (don't try a Rpi5). I've played around with this board a bit using SPI, EPP and with modded SSerial code and used it as a smart serial device.

I found the best way to achieve 3.3v to 5v translation is to replace all the buffers on the non commoned lines with SN74CBT3245 and power the board with 4.2v. Tho on the "outside world side" the signal will need pulling up to 5v via a resistor.

I did the upgrade according to the IlyaKw suggestion forum.linuxcnc.org/27-driver-boards/4773...901t?start=30#272597 and then just downgraded the input voltage of RV901T to 3.5V - it was enough to flash the bitstream to FPGA with the Xilinx ISE. So I decided to still with that solution for a while, but I ordered the SN74CBT3245 already, thanks!

And those reasons would be ?
Based on what ideas ?

I am not sure about the reasons honestly, I spent about an hour in order to understand how to enable SPI or my rpi4. In STM32 with CubeMX it was not so big challenge). But I took into account two points:
1. I did not see solutions with GPIO7-11 of SPI0 in the internet success stories related to rv901t and rpi
2. I do not actually know whether SPI0 is already taken with some internal peripheral sensors or eeprom or somewhat else.

Code:
ls /dev | grep spi
gives: /dev/spidev0.0

Code:
lsmod
shows tons of the output - not sure how to interpret the results...
I know that I didn't use SPI0 explicitly but not sure that some internal sensor or board chip is not connected there for system needs.
Last edit: 2 years 7 months ago by ago_tm.

Please Log in or Create an account to join the conversation.

More
2 years 7 months ago - 2 years 7 months ago #296690 by Cant do this anymore bye all
Replied by Cant do this anymore bye all on topic Need help with RV901T as MESA 7i90: SPI isn't working
There's no need to mess around with any spi defaults.

All that is required is to enable SPI is add this line to config.txt
dtparam=spi=on

I wouldn't worry too much looking into what drivers are loaded, if you have /dev/spidev0.0 all is good.

I've run various dev boards with modified versions of 7c81 & 7i90 firmware using the vanilla SPI interface and it all runs fine.

So if you enable the SPI interface without playing around with CS it will work fine. There's a few threads relating to using Mesa firmware on some Aliexpress dev boards, it works fine on a Mimas Spartan 6 dev board, just the dcm values need to be adjusted and to make sure the SPI comms is on the correct bank, but this comes during the compilation stage of the firmware.

The Linuxcnc-RIO project uses lattice fpgas and SPI on the RPi4 with no modifications required to the SPI pins.

Even the 7c81 doesn't require any messing about with.

As regarding your idea that something maybe connected to the SPI interface, that would be fine if the interface was enabled by default.

Once the default SPI interface is enabled it's all plug & play with the Mesa boards.Easier than ethernet as there's no IP addresses to set.

And honestly I've found these type on boards to end up being more expensive than a genuine Mesa product, but unfortunately the 7i90 is out of stock. At face value they appear cheaper, but as they are they are not entirely suitable, electrically, for a cnc machine. And if we're being honest a mess of dupont cables with eventually give you trouble.

This is an example of the way I've gone.
forum.linuxcnc.org/show-your-stuff/51142...tan-6-fpga-card-9d60

I actually modified the Linuxcnc driver & mesaflash utility to support the card with a custom ID I gave to the card, as well as the IP Port arrangement. Although it will work fine with 7c81 with only mods to the DCM setup, to allow for a 100MHz crystal.
Last edit: 2 years 7 months ago by Cant do this anymore bye all.
The following user(s) said Thank You: ago_tm

Please Log in or Create an account to join the conversation.

More
2 years 7 months ago #296691 by Cant do this anymore bye all
Replied by Cant do this anymore bye all on topic Need help with RV901T as MESA 7i90: SPI isn't working
Some other info that maybe of help
forum.linuxcnc.org/38-general-linuxcnc-q...-7c81?start=0#273546

forum.linuxcnc.org/27-driver-boards/3639...i90hd?start=0#130972
The following user(s) said Thank You: ago_tm

Please Log in or Create an account to join the conversation.

More
2 years 7 months ago #296756 by ago_tm
Replied by ago_tm on topic Need help with RV901T as MESA 7i90: SPI isn't working
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 or Create an account to join the conversation.

More
2 years 7 months ago #296768 by ago_tm
Replied by ago_tm on topic Need help with RV901T as MESA 7i90: SPI isn't working
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 or Create an account to join the conversation.

Moderators: PCW, jmelson
Time to create page: 0.421 seconds
Powered by Kunena Forum