Icebreaker v1.0e -- diodes D1 and D11 are shorted

icebreaker-fpga / icebreaker

Small and low cost FPGA educational and development board

549 stars 74 forks source link

Icebreaker v1.0e -- diodes D1 and D11 are shorted #50

Closed 71GA closed 2 years ago

71GA commented 2 years ago

I was playing with an SPI and found out that sometimes there is a glitch immediately after data has been sent. There is an entire discussion about this here.

After checking out the PCB we found out that:

diode D3 is in a short circuit! Therefore during SPI communication a lot of signals will drop to approx 2.5 V instead of 3.3 V and possibly FPGA resets because of the high current through the LED. If you can... remove the D3...
Now check the D11... None of the channels from this RGB LED have resistors!!! Luckily the connector D11 is empty, but this is pure luck... Don't ever solder anything there...

What was the hardware designer thinking?

gatecat commented 2 years ago

I can't see the problem with D3? CDONE is an open drain output from the iCE40.

and there are no resistors for D11 because the iCE40 has a built in constant-current sink driver on those pins (SB_RGBA_DRV)

71GA commented 2 years ago

Is there any way to help clear out the things at the link that I posted. SPI is really acting strange. We are out of ideas.

smunaut commented 2 years ago

Are you trying to talk to the FPGA itself (slave config mode) or some of your own logic loaded on the FPGA ?

In the first case, you need to change the board wiring, by default it's not wired for that ... SI/SO need swapping and the flash needs to be disconnected. You also need to assert the FPGA reset line

In the second case, you're using the wrong chip select line, this will conflict with the flash.

esden commented 2 years ago

Have you made any additional tests @71GA ? I think some of your understanding and assumptions regarding the circuitry might be wrong. We are using the FTDI SPI interface in many different modes and have not observed issues that you are describing.

In your original description you say that for example 1v2 rail comes up after 3v3 which should not be possible because 3v3 has quite a big startup delay added on the EN pin.

I am having a hard time understanding what exactly you are trying to do. As @smunaut mentioned, you should clarify how you are trying to use SPI in your particular case. Are you trying to write data into a running FPGA, or are you trying to use the SRAM programming mode? So we still need to get on the same page before we can consider trying to resolve your issue.

Maybe we will be able to help if you try to boil down your original question a little bit? Especially now that you have learned a few more things of how the circuit is working. :)

smunaut commented 2 years ago

Closing as there is obviously nothing wrong ....