q3k / chubby75

Linsn RV901T HUB75 LED "Receiver Card" Reverse Engineering
Creative Commons Zero v1.0 Universal
531 stars 103 forks source link

RV901T inputs 5V #85

Closed mmueller-kaffeeschluerfercom closed 1 year ago

mmueller-kaffeeschluerfercom commented 3 years ago

For RV901T, the I/O direction of some of the 74HC245 buffers can be set by the FPGA on pin F13 (U600-U607, see Section Buffer. But the VDD on U600-U607 is at 5 V and like also mentioned in #37 for the 5a-75B, the 74HC245 buffers drive the FPGA inputs at 5 V when configured as an input buffer (the 74HC245 is directly connected to the FPGA pins). According to Xilinx, the Spartan-6 is not 5 V tolerant, meaning that it would damage or destroy the FPGA if the buffers are configured as inputs.

Am I missing something or is the board really designed that way?

Shouldn't this be mentioned in the Hardware description?

At least, the DIR input of the buffers is pulled to GND by R608, so during configuration of the FPGA, the buffers are configured as outputs and likely stay like this if the new design does not configure F13.

pauluzs commented 3 years ago

If you don't need the 5v output level and the 5v tolerant input level try to run the board on 3.3V This works for me when feeding 3.3V into the 5v line which also feeds the 3.3v regulator. Or you could also try and feed the 3.3V directly on JP2

mmueller-kaffeeschluerfercom commented 3 years ago

Thanks a lot, great to know the board works with 3.3 V!

But do you agree with me it's a bad idea to put F13 to high when powered with 5 V? If yes, I would propose to mention it in the hardware description.

pauluzs commented 3 years ago

According to linsn's datasheet the board should work between 3.3 and 5.5v And according to the 74HC245 datasheet the buffers should work between 2.0 and 6.0 V

Been running it as a mesa 7i90 card with hostmot2 firmware over spi to linuxcnc on a raspberry pi 4 for several months without any problems.

Albeit still using external 5V > 3.3V level shifters on the inputs. As the 74HC245's datasheet states: max. input voltage = VCC . So when working of 3.3V the inputs would not be 5V tollerant as far as i can tell.

mmueller-kaffeeschluerfercom commented 3 years ago

If I understand correctly, the 74HC245 datasheet, section 7, table 4 (absolute maximum rating), states that the input clamping current must not exceed 20 mA (at condition VI > VCC + 0.5 V). So, assuming the clamping diode has a voltage drop of 0.5 V, the remaining (5 - 0.5 - 3.3) = 1.2 V drops in the current limiting resistor, which is 75 Ohm on RV901T, so there would be an input current of 16 mA which is 80 % of absolute maximum rating. Dirty hack but may work. So at least in theory, at VCC = 3.3 V, the 74HC245 inputs should be 5 V tolerant with a current limiting resistor of 75 Ohm.

Bleeptech commented 2 years ago

pauluzs commented...

"Been running it as a mesa 7i90 card with hostmot2 firmware over spi to linuxcnc on a raspberry pi 4 for several months without any problems."

Do tell! Details man, details! LOL

Peter-van-Tol commented 2 years ago

pauluzs commented...

"Been running it as a mesa 7i90 card with hostmot2 firmware over spi to linuxcnc on a raspberry pi 4 for several months without any problems."

I'll second that: definitely want to know more. Do you have any links on how you flashed the firmware to the card? Is it by coincidence that the Mesa and the RV901T uses the same chipset?

On the other side: thanks to the great work in this repository there is also a development to create a dedicated firmware and driver for LinuxCNC which works on ethernet: https://github.com/Peter-van-Tol/LiteX-CNC/tree/main (still work in progress).

Will try to run the board at 3.3 Volt and modify the buffers to fix in and outputs.

pauluzs commented 2 years ago

Sorry for the late reply, Didn't see @Bleeptech 's comment.

It's been a while so i had to search my backups to see what i could find. In short i made a custom .ucf and .vhd for the rv901's fpga LED1 (F13) is used to switch the buffers between input or output. RV901Tspi.ucf.txt RV901T_x16card.vhd.txt You also have to change the package type in the.xise file (Hint use the same naming as for the standard 7i90 if you don't feel like compiling a custom version of mesaflash for your custom card)

Flashing was done by writing the bitstream with openocd on the raspberry pi connected over JTAG. This requires soldering and first flashing a spi_bridge bitstream connecting the flashroms pin with the JTAG pins and then writing the bitstream to memory.

The easier method is using the flashrom program on one of the Pi's SPI ports and directly connected it to the flash memory on JP5 , no soldering needed as standard dupont jumper wires will fit and no bridging bitstream is needed. (This works with normal programmers as well) Don't use a gpio to pull the card in reset as it can't handle the current. instead use a jumper wire or switch from JP5(PROG_B) to ground on the fpga card.

The linuxcnc spi>fpga connection was made at jp4, which has 4 non-buffered pins at 3.3V (needs pins soldered)

Did find some notes made when i did this , this includes the whole process, for the fpga flashing see line 180 and down Read carefully, not all is needed and not all is in right order(these were just some notes not a howto) pi4_5.9_rt_linuxcnc.txt

Hope this will help you out If someone takes the time to implement the card's nic into hostmot2, this could also be used like a 7i80 over ethernet with normal pc hardware

Br Pauluzs

edit, Also this forum post for some extra info on the clocking

Is it by coincidence that the Mesa and the RV901T uses the same chipset?

Its not the same fpga as the 7i90, but did pick the rv901 because its the same xilinx brand and was able to use the existing project and toolkit without starting from zero for a colorlight card. As well as this card can also be used for inputs, which is not possible without modding for a colorlight card.

Btw, Can confirm using inputs for encoders also work like a charm

tomverbeure commented 1 year ago

@ericfont Eric, I have merged your pull request. Do you think this is sufficient to close this issue? Tom

ericfont commented 1 year ago

yes, I think this can be closed now, thanks.