Trying yet again to revive comatose DE10-Nano

[aeberbach]

I have put this away for about a year now and periodically I pull it out to try and revive it. I always figure I will buy another when available but they never are, then I want to do something that only my MiSTer can do so I try again.

What it does:

Terasic Linux BSP MicroSD card image: "De10_Nano_Xfce" Boots to desktop! No issues.

Mister Fusion: OPens with blue screen then switches to black screen with text "Please stand by..." After about two minutes reboots. Blue, orange, LED0 are lit. USERLED flickers for 20 seconds or so, then HDMI shows the "no signal" alert and no further activity after that.

Reading threads I thought to check voltages at test points. Every test point measures as marked. There are two test points, one to the right of the lower DDR3 that measures 0.74V. There is another marked VREF near the ethernet jack measuring 0.747V. Not sure if these last two are correct since I can't find them on the schematic. Also one of the power circuits shown on page 1 is 0.75V, so this is probably right.

Have tried 3 different SD cards all of which are fine booting Linux on this thing or used in a Pi.

Microswitches (SW10) are in position ON-OFF-ON-OFF-ON-ON. Four switches are off (towards header).

I believe this is a rev C because the number on the back ends in C0 so I have the rev C Hardware CD-ROM image.

Have installed Quartus Prime Light 22. Re-programmed the FPGA using the Default bitstream DE10_Nano_Default.sof - no change with Mister Fusion on SD and switches back in default positions. Flashed my_first_fpga.sof from CD, binary counting on LEDs 7:0. Flashed DE10_Nano_Default.sof again, displays DE10 image on HDMI display and flashes LEDs 0,2,4,6 then 1,3,5,7 then all together then all off.

Plugged a PuTTY terminal into UART - saw a login prompt displayed. Logged in as root, went to /media/fat/Scripts, ran ./update.sh with ethernet attached. Ran the downloader, unpacked lots of things, downloaded 17,xxx files. But after the reboot, no screen!

Clearly something is working but nothing shows up on the screen

[GreyAreaUK]

What display device are you using? I had a similar issue when I intially tried using a monitor with a lower resolution than the MiSTer was expecting.

The way I fixed it was to ssh over to the MiSTer (which I think you can do?) and alter mister.ini to have

video_mode=1

which sets it to 1024x768 60Hz mode.

You could also try values of 5 (800x600 60Hz) or 6 (640x480 60Hz)

[aeberbach]

No trouble copying MiSTer_example.ini to MiSTer.ini and trying a few video_mode settings, but it wasn't that.

[GreyAreaUK]

No trouble copying MiSTer_example.ini to MiSTer.ini and trying a few video_mode settings, but it wasn't that.

And yet weirdly it feels like that's what it is - you get a display when you run the initial MiSTer install and it's resizing the card, so the HDMI port seems good.And you can ssh to it, so it is running.

Do you have another display and/or HDMI cable you could try?

[aeberbach]

OK, tried that. First monitor was an "Arcooda" 20" - actually a LG panel with a driver card that does 15-kHz-capable VGA as well as HDMI, the Mister used to work on it. I grabbed another cable and tried it on a a Dell 34" via HDMI but same result.

Also just tried Mister Fusion releases 1.0 and 2.0 as well as the latest 2.7, all the same.

[GreyAreaUK]

This is bizarre (to me). You get video output with other bootable OSs, just not MiSTer, yes? If so, to me that suggests a video configuration issue (although I freely admit to not being any sort of expert).

Anything else plugged into the DE-10? RAM module, analogue board, etc?

[12characters]

Have you tried pressing F9 to see if the Linux terminal might appear on your screen?

[thorr]

Have you tried contacting Terasic? They may be able to help you, and at a minimum, that is the place you can buy new ones quickly.

[aeberbach]

Nothing was plugged into the DE10 for the above tests, not even the SDRAM module.

Attached USB hub for the keyboard test, F9 no response.

I haven't contacted Terasic about this but if Linux works I don't think they will want to know.

[Flandango]

From the putty image you posted, it looks like it's not loading the menu.rbf.
So...try downloading it manually and popping on the SD card.
From the looks of it, the linux system it updated to is 221224 so try downloading https://github.com/MiSTer-devel/Menu_Mi ... 221224.rbf and naming it menu.rbf in /media/fat
(Other releases are at https://github.com/MiSTer-devel/Menu_Mi ... r/releases)

If your mister does have internet access, then using the putty terminal over UART, log in go over to /fat/media and type this:

Code: Select all

 wget https://github.com/MiSTer-devel/Menu_MiSTer/raw/master/releases/menu_20221224.rbf -O menu.rbf

[aeberbach]

I get file size 2438576 with the new menu.rbf but no change.

Is "socfpga_bridges_reset: FPGA not ready, aborting" at all significant? It might appear in every log for all I know but most people including logs and describing similar problems show this line.

[Flandango]

That message is normal...I get it too.

[jca]

You can always contact Terasic: they are very friendly and answer quite rapidly.
Once I had a strange problem: I turned on my MISTer and just got a black screen. The day before it was working fine and the only thing I did was turning it off. After double checking everything I contacted them (not mentioning MISTer), they asked me if I was running the original software to which I replied no so they recommended to use the original software, making sure the DIP settings were correct. This gave me an idea before testing with the original software: although the DIP switches cannot move by themselves I moved each one back and forth a few times and when I powered my MISTer it worked. The DIP switches were in the correct position but there must have been a bad contact.
You could try that to see if it fixes your problem. May be not: I just did a search as your post is "Trying yet again ..." I see that I already mentioned it and that it did not work in your case. I guess I also mentioned that someone fixed his by using JTAG.

[Flandango]

So after looking at your output and comparing to a fresh build (fusion 2.7), it looks like "main" is exiting at the point it is trying to read the core's "confstr". It's possible that either the Menu core (menu.rbf) isn't getting loaded or there is an issue with the HPS side retrieving the information from the FPGA side (speculation on my side).
One thing you can try, just for testing/amusement purposes, is from the command line type

Code: Select all

fpga /media/fat/menu.rbf

It should tell you that it's loading the bytestream...
then either hit the reboot button on your IO board if you have it installed or type reboot on the command line.
All this does really is verifies the menu.rbf is loaded in the fpga and, if it comes up after the reboot (not a powercycle) then it means that something is either clearing the fpga before Main has a chance to read the confstr or simply the rbf isn't loading in properly during bootup.
If it still doesn't come up, try as JCA is recommending and try toggling the dip switches a few times.

The test I did was on a fresh build, no config at all and using an LCD TV that can do 1080p and 4k and defaults to 1080p.

[aeberbach]

It did something...

Bitstream size: 2438576 bytes
GPI[31]==1. FPGA is uninitialized?
FPGA is not ready. JTAG Uploading?
Waiting for FPGA to be ready...

then the prompt is displayed briefly, and then it reboots without me having to type reboot or hit a button.

So from looking at code, fpga_gpi_read is returning a bad value. The error routine that prints those messages causes a reboot as it exits.

If there's a way to put the FPGA back into a known state that might be a thing to try or if not that's at least a definite fault.

Playing around further if I power off, put all the dipswitches down ("OFF") then doing the same results in

Bitstream size: 2438576 bytes
Error -6 while loading menu.rbf

and no reboot.

[C-R-T]

Clearly an ESD damaged unit. The healthy thing to do here is to stop obsessing over a dead object and just toss it in the bin and move on. It’s not getting fixed, and all time spent on it is time wasted. Not just yours but the people in this thread. There are new ones, get one if you need it.

[thorr]

You can get one right now here: https://www.digikey.com/en/products/det ... 96/6817231

[aeberbach]

@thorr Not yet... Australians not allowed apparently. Every time I am redirected to .au or login, stock is zero. Every time I avoid my account cookies and try to checkout as guest, when the shipping address is entered final order screen changes to look like the attachment - backordered. (These kinds of shenanigans are why I like Mouser. I backordered one at Mouser, expected in 3 weeks.)

@C-R-T As for wasting time, the title of the thread is clearly marked - you should be able to avoid it easily enough if it bothers you. I'm grateful to have learned a few things in this thread so I don't see the problem.

[jca]

...
@C-R-T As for wasting time, the title of the thread is clearly marked - you should be able to avoid it easily enough if it bothers you. I'm grateful to have learned a few things in this thread so I don't see the problem.

Exactly.
On this forum there are a few useless topics but I don't see the need to make a post saying it is time to cut it off.

[LamerDeluxe]

It is a good thing to have thorough MiSTer troubleshooting threads, because having a MiSTer that stops working all of a sudden is not a fun thing, I've been there.

[aeberbach]

I went through several troubleshooting steps with Terasic before finally being given a RMA number, and I shipped the board back to Terasic at my own expense. They say "FPGA needs to be replaced." However, it would cost more to replace the FPGA than to just buy a new one...

So if your DE-10 Nano is not working and you can point to the FPGA being the likely cause don't bother wasting your time or money investigating repair, because they make it obvious that it's not a financially viable option. After you waste your money sending them the board.

[LamerDeluxe]

Good thing you finally found out the cause and can get it replaced. No wonder it took so long to find out, when the FPGA itself turned out to be the problem.