Low voltage SPI bus compatability

[osresearch]

The GPIO pins are set at the 3.3v signalling right now. Can the bitstream select 2.5v or 1.8v at runtime?

[goran-mahovlic]

If you remove RV3, and put 3 pin jumper on J5 - you can easy switch left side Voltage from 3.3V to 2.5V

I need to ask emard if 1.8V can be used ...

[goran-mahovlic]

You can connect 1.8V on middle pin if J5 that will give you 1.8V on left side of the board.
We did not try if LEDS will be visible on 1.8V but you can check that...

Or you can use 1N914 diode on RV2 position (you would need to remove resistor from RV1)
That would give you 2.5V - 0.7V (diode) = 1.8V on left side ....

[emard]

Remove RV3 jumper first! Connecting both RV2 and RV3 will overvoltage the FPGA.

Solder 2.54 mm 90 deg 3-pin angled headers
On this header at 2.5V jumper position (RV2)
connect small general purpose silicon diode with 0.7V drop
like 1N914 for 100mA or higher current rated if you need more current.
2.5V-0.7V = 1.8V
Drawback would be that LEDs will be too dim or not lit at all but left
GPIO banks (pin pairs GP,GN 0-13) should be operating at 1.8V

It is probably not possible to switch GPIO bitstream voltage setting
at runtime but I guess you can leave that fixed set to 2.5V or 3.3V
and just apply 1.8V supply.

some hi speed signal timings should be not optimal in such case,
but for the slow SPI flash emulation it should be good enough.

[osresearch]

There might be an even easier hack to get the right voltage on the SPI bus outputs - if I remove RV3 and solder a header to connect to the mainboard's SPI Vcc, then the left IO bank will be correctly powered for whatever the board expects. Are there any problems if the J5 center pin is floating or grounded some of the time?

[osresearch]

This hardware mod seems to work. The lack of LEDs is a minor problem, although once the mainboard comes online they are fine. I've only tested on a 3.3v mainboard; the 1.8v one went away while I was soldering.

[emard]

HI

I was testing boards with voltage selection pin floating (no RV2 no RV3).
Boards are working except of course related hardware LEDs DIPSW that's
not powered, so temporary not working. I can hotplug RVx jumper at any time
and LEDs and everything starts working. Of course external power can be applied
and this is just fine for ULX3S but it will draw current.

external power can be weak or current limited. To save few mA
don't use LEDs or any other related bank pin that's not really neccessary.

ULX3S has some C at this RV2/RV3 I think around 30uF, so at powerup
it will also draw current initially until C is charged.

[osresearch]

Re-opening since this seems to be problematic with starting the user bitstream.

With no voltage on the bank, the user bitstream resets to the bootloader almost instantly. Perhaps the pullup for BTN0 is wired to this rail, so the bitstream thinks that the user is pressing the reset button.

[emard]

I have few theories: 1. If you have added ESP32 module and loaded it with firmware then BTN0 will appear as constantly pressed and usually passthru bitstream has wifi_gpio0 <= btn(0) and that would make board constantly reset. It's fixable by recompiling 2. Also, some bitstreams have BTN0 wired to user_programn this also would have similar effect with unpowered bank user_programn <= btn(0); its fixable by recompiling 3. If there's D28 mounted then it will hardwire BTN0 to programn, it's fixable by removing D28 But strange, if there's no ESP32 module and no D28 and programn <= btn(0) is not compiled, then the board should not reboot from unpowered RV2/RV3

…

On 8/30/19, Trammell Hudson ***@***.***> wrote: Re-opening since this seems to be problematic with starting the user bitstream. With no voltage on the bank, the user bitstream resets to the bootloader almost instantly. Perhaps the pullup for BTN0 is wired to this rail or perhaps the WIFI gpio needs voltage to prevent the reboot? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #10 (comment)

[emard]

odgovorio sam mu slično ko i tebi tak da ako je sjelo na git issues nemoraš mu forwardirat hmmm

…

On 8/30/19, D EMARD ***@***.***> wrote: I have few theories: 1. If you have added ESP32 module and loaded it with firmware then BTN0 will appear as constantly pressed and usually passthru bitstream has wifi_gpio0 <= btn(0) and that would make board constantly reset. It's fixable by recompiling 2. Also, some bitstreams have BTN0 wired to user_programn this also would have similar effect with unpowered bank user_programn <= btn(0); its fixable by recompiling 3. If there's D28 mounted then it will hardwire BTN0 to programn, it's fixable by removing D28 But strange, if there's no ESP32 module and no D28 and programn <= btn(0) is not compiled, then the board should not reboot from unpowered RV2/RV3 On 8/30/19, Trammell Hudson ***@***.***> wrote: > Re-opening since this seems to be problematic with starting the user > bitstream. > > With no voltage on the bank, the user bitstream resets to the bootloader > almost instantly. Perhaps the pullup for BTN0 is wired to this rail or > perhaps the WIFI gpio needs voltage to prevent the reboot? > > -- > You are receiving this because you commented. > Reply to this email directly or view it on GitHub: > #10 (comment)

[osresearch]

As of yesterday I added a power button to user_program connection... 851c737

It looks like the other buttons are wired to 3.3v on a different bank, so I can move the "reboot" function to those instead.

[emard]

that explains everyhting :) programn is useful to reload the bitstream or jump to next multiboot image. for programn you can use BTN1 with some debouncing or delay counter, do not use simple programn <= not btn(1); but something similar with the counter if btn(1) then counter++ else counter = 0 programn <= counter(counter'high);

…

On 8/30/19, Trammell Hudson ***@***.***> wrote: As of yesterday I added a power button to `user_program` connection... 851c737 It looks like the other buttons are wired to 3.3v on a different bank, so I can move the "reboot" function to those instead. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #10 (comment)

[osresearch]

Thanks for the advice! Remapped to button RIGHT and it seems to work fine 64f41b6...37beda0

[osresearch]

This modification worked on an ASUS x370-pro board with AMD CPU running the flash at 1.8v via the programming header.
Three caveats, however:

• the board had no flash chip installed so TOCTOU/override mode was not tested
• the x86 flash speed was not selectable, so we were only able to emulate the PSP boot and legacy reset vector
• the LEDs do not light up.

[emard]

Eeehheheheee wonderful example of advanced usage of ULX3S Maybe it's off topic, but I heard you also like some fast upload to SDRAM. I have usb-cdc ethernet core but it's not fully stable. Few errors on usb bus and my latest linux debian 5.2.0 will freeze :). Other option is 100Mbit RMII ethernet module pin compatible for our boards, get it cheap 2.2$ from here https://www.ebay.com/itm/1pcs-Smart-Electronics-LAN8720-network-module-Ethernet-transceiver-for-arduino/183479331440?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2060353.m2749.l2649

…

On 9/3/19, Trammell Hudson ***@***.***> wrote:  This modification worked on an ASUS x370-pro board with AMD CPU running the flash at 1.8v (via the programming header, although the board had no flash chip installed so TOCTOU/override mode was not tested). -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #10 (comment)