Modify MiSTer Main to bring broken DE10 back to life

[arago]

Hi everyone! I need some assistance from MiSTer devs to modify and compile Main code in order to bring back to life a dead DE10 Nano.

TL;DR:

• DE10 Nano has shorted GPIO17 (Reset), confirmed via multimeter
• Board behaves as if the reset button is constantly pressed, preventing the load of MiSTer
• Need help to modify MiSTer Main to prevent reading the reset button (if possible)

Almost two years ago, my “first” MiSTer broke by means of an electrical static discharge when pressing the reset button on the IO Board without any case: Static electricity discharge killed DE10. From that day forward, I have seen many people in the forum reporting killing the DE10 due to static.

In particular, later this year GamingDoyle had a very similar issue and found an easy fix. In his setup, the DE10 Nano had a short between GPIO Pin 13 (OSD) and ground, meaning that the button was pressed all the time. That caused the menu to be displayed all the time (Disable Bluetooth). Based on his conversation with Terasic Support, I ran a diode test on all 36 GPIO1 pins (D0-D35) that are not power/ground (11, 12, 29, 30 in the 2x20 header). Here is what they asked him to do:

You can test the GPIO I/O pins, power off the board, set the switch of multimeter to the diode label position, red probe connect to GND, black probe connect to 36 I/O pins one by one. Pay attention to the power pins, don't touch them, then tell us the result for analyzing.

I found that in my DE10 Nano, the GPIO1 Pin 17 (RESET) is shorted, while all the other pins are working correctly. This was always my suspicion and it is good to finally being able to confirm it. I have the theory that because the reset button is always pressed, the MiSTer code is not able to start correctly, therefore rendering the board useless. And that also explains why other payloads, such as the linux distribution provided in the DE10 sd card and the MiSTer fusion image work well (i.e., these are ignoring GPIO17).

Based on the findings above, my goal is simple. I want to modify the code of MiSTer Main to avoid reading that GPIO pin entirely, and therefore bypassing the issue and bringing the DE10 back to life. However, after reading the code I am very confused. Looks like the reset behavior is much more complicated than that of the OSD/User buttons. I have been playing with the code, commenting out functions in fpga_io.cpp and recompiling the binary without success. A few things that I have tried:

• Commenting out fpga_get_buttons and returning 0 (GamingDoyle’s solution, only applies to OSD and MENU) fpga_io.cpp#L567
• Commenting out reboot fpga_io.cpp#L581
• Commenting out fpga_core_reset fpga_io.cpp#L631

So far nothing has worked. I have the suspicion that there is some check in a loop that is preventing MiSTer to start because the state of the board is not correct. Maybe someone can confirm and assist me to bypass that check in my custom fork.

Summarizing, my questions are the following:

1. Where is the code that references GPIO17 and reads it. If there are more than one place, which one is critical for booting up?
2. Why are GPIO13/15 referenced like this? That could help me to understand the code better [gpi >> 29) & 3]
3. Is there some kind of check that reads GPIO17 to evaluate the status of the board?

Thanks in advance, any help would be appreciated, specially now that so many new cores are being developed/released. It is a crime to have a DE10 board stored in a box and not being able to use it.

[thorr]

Sorry, I can't help with modifying the code, but did you look at the circuit board? Perhaps there is a bridged solder connection somewhere in the trace that goes to GPIO17. If you can find the bridged connection, you might be able to just repair it. It might also be a failed component that connects to GPIO 17 like a resistor or something and it might be shorting to ground because the component isn't doing its job. You may be able to test any of these components with your multimeter for ohms. Also, if you are using an I/O board, try removing it.

[arago]

Yes, I did look at the circuit board but couldn't find anything that could indicate what is broken/burnt.

About the resistor or something that might be causing the problem, it is a really good idea but I don't know where to start looking in the board and not sure how to test that with the multimeter. I am assuming that different components should be tested differently. I checked the documentation of the DE10 nano and found this. Maybe someone can explain what TPS3831 is doing and where is that located in the board.

IMG_0017.jpg (470.69 KiB) Viewed 16645 times

The IO board is disconnected, it is the first thing I tried.

Thanks for the help, I am more inclined to modify the source code and recompile MiSTer main because (1) I can live without the reset button and (2) I won't probably update very often.

[zakk4223]

Main doesn't handle it. You can kill the MiSTer process and that button still functions as a reset button

[jca]

May be the reset is handled by Linux (the MISTer version). If the board functions properly with the standard software from Terasic that would confirm it. In this case it is Linux which would have to be modified.

Edit:
In the De10 Nano manual:
3.4 Board Reset Elements
There are two HPS reset buttons on
DE10 Nano HPS ( cold) reset and HPS warm reset as
shown in Figure 3 13 Table 3 4 describes the purpose of these two HPS reset buttons.
Figure 3 14 i s the reset tree for DE10 Nano

They are on the HPS side which is the ARM side. May be it would be a good idea to see with Terasic how they are handled.

[thorr]

There is no mention of GPIO17 in that diagram so I would be inclined to believe that it is a software function that programs GPIO17 to be a reset. Regarding the bad component, trace the "wire" from GPIO 17 all the way to anything it touches on both sides of the circuit board, and hook the multimeter up to both sides of each component that touches the "wire" with the Ohms setting or the beep setting that beeps when there are 0 ohms. Anything that beeps could be, but not necessarily be, the bad component if there is one.

[arago]

So this weekend I had a breakthrough, my dead DE10 is alive and kicking again! I will report the findings and how I did it later today.
Thanks everyone for the help, I couldn't have done it without your insights!

IMG_2601.jpg (5.17 MiB) Viewed 16409 times

IMG_2599.jpg (5.8 MiB) Viewed 16409 times

[KneeTie]

Wow that's great news, please do share your findings. I had my dead DE-10 revived by using a modified MiSTer.rbf that was posted by GamingDoyle.

[arago]

Ok, so here is what I did. Sorry for the delay, work and life got in the way

I was failing to identify any clear reference to GPIO pin 17 in the code or the diagrams, as 'thorr' clearly suggested in one of the comments. Until I saw this image:

20-pin_header_pin-out.png (101.81 KiB) Viewed 16266 times

Here, the reset button connected to GPIO17 is actually referred to as GPIO_1[14] or by label 'PIN_AG23'. This finding opened another avenue for searching and tweaking things. I apologize if this is dumb on my part, I am learning this stuff as I go.

Using the diagram above:
OSD BUTTON -> GPIO13 or GPIO_1[10] or PIN_AG25
USER BUTTON -> GPIO15 or GPIO_1[12] or PIN_AH24
RESET BUTTON -> GPIO17 or GPIO_1[14] or PIN_AG23

Then I went back to the MiSTer GitHub and started finding references to PIN_AG23 in the repos, but instead of finding this in MiSTer Main as I thought initially, it was the actual cores that were referencing the GPIO used for resetting. That makes sense I guess, since those are general purpose lines that can be programmed for whatever the developer wants.

This setup is part of the MiSTer framework, as seen here: https://github.com/MiSTer-devel/Menu_Mi ... og.tcl#L67

Code: Select all

#============================================================
# I/O #1
#============================================================
set_location_assignment PIN_Y15 -to LED_USER
set_location_assignment PIN_AA15 -to LED_HDD
set_location_assignment PIN_AG28 -to LED_POWER

set_location_assignment PIN_AH24 -to BTN_USER
set_location_assignment PIN_AG25 -to BTN_OSD
set_location_assignment PIN_AG23 -to BTN_RESET

set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to LED_*
set_instance_assignment -name IO_STANDARD "3.3-V LVTTL" -to BTN_*
set_instance_assignment -name WEAK_PULL_UP_RESISTOR ON -to BTN_*

At this point, I downloaded Quartus Prime and set everything up in my computer to build a new version of the Menu core, but modifying that piece of configuration to avoid the broken GPIO pin 17 in my DE10 nano.

Basically, what I did is the following:

1- Swapped pins between BTN_USER and BTN_RESET (that way, MiSTer will boot but the user button would be pressed all the time).

2- Disabled the 3.3V connection to all the buttons, just in case there is a problem due to the shorted pins (overheating or something like that - I might be mistaken, please correct me. I don't care about the buttons working at all at this point).

3- I recompiled MiSTer Main to avoid reading BTN_USER and BTN_OSD, as this previously worked for GamingDoyle.

pin-assignment-changes.png (123.97 KiB) Viewed 16266 times

main-changes.png (156.19 KiB) Viewed 16266 times

After that, and seeing that MiSTer booted up correctly, I recompiled several cores, including NES, SNES, Genesis and PSX. All four worked correctly.
I also tried the original cores released by the distribution system (releases folder in github), and those have the same issues that before and do not boot in my broken DE10.

I know that this is very cumbersome, and I would like to modify MiSTer main to avoid reading the input sent by the core to the linux/HPS side of things, making it more clean and simple. But at least now I know the system works and I confirmed that there is 0 damage to the FPGA.
Updating things will be painful since I basically have custom builds for all cores and Main, but hey, this is the advantage of FPGA cores, once the core is completed there is no need to be updating the system on a daily basis.

I don't know if it is correct to share the compiled cores here, but if anyones needs to try, please send me a DM and I will provide

Here are a few snapshots of the different cores that I tried:

nes-snapshot.jpg (2.17 MiB) Viewed 16266 times

genesis-snapshot.jpg (2.4 MiB) Viewed 16266 times

snes-snapshot.jpg (3.1 MiB) Viewed 16266 times

psx-snapshot.jpg (3.02 MiB) Viewed 16266 times

[jca]

This is really detective work and I am glad you figured it out. Recompiling the cores is a pain but at lest you have a temporary solution. Modifying MISTer main would be the ideal solution and I hope you figure it out.
I have a question:
Where are these mentions of GPIO13, 15 and 17? This is plainly wrong. They should be referred as J7 Pins 13, 15 and 17 or GPIO-1 Pins 13, 15 and 17.

[arago]

I have a question:
Where are these mentions of GPIO13, 15 and 17? This is plainly wrong. They should be referred as J7 Pins 13, 15 and 17 or GPIO-1 Pins 13, 15 and 17.

The information is coming from the DE10-Nano User Manual:
1) Figure 3-20 - GPIO Pin Arrangement (Page 28)
2) Table 3-10 - Show all Pin Assignment of Expansion Headers (Page 29)

I think that the naming convention for the GPIO pins depends from where you are looking. For the reset button in mister it would be:

• From the FPGA: PIN_AG23 ==> this is the name shown in Quartus Prime and used in the MiSTer framework
• From the ARM/HPS: GPIO_1[14] ==> the array starts in 0 and does not have 5V/3V/GND pins
• From the hardware viewpoint: JP7 Pin 17 ==> it is the 17th pin of the 40-pin expansion header

This is the pin planner in Quartus Prime for example. Check out the third column in the table at the bottom of the image.

pin-planner.png (456.56 KiB) Viewed 16167 times

[jca]

Thanks for the answer. I understood what you said in your first explanation.
May be I did not make my question clear enough:
"Where are these mentions of GPIO13, 15 and 17?"
The question is about these exact terms: GPIO13, GPIO15 and GPIO17. Where do they appear?
Clearly this information appears somewhere but this is wrong and should be rectified. There could also be some other incorrect GPIOs in the same document.

[Flandango]

The GPIO13,15 and 17 are the physical pin on GPIO-1 on the board referenced in the IO-Board 6.1 schematic, as the IO-Board only connects to one of the two GPIO interfaces, it doesn't really bother to name it GPIO_1-13, GPIO_1-15...etc.
The internal names to DE10-nano for those pins are as Arago mentioned above, the GPIO_1[XX] because they are not pin for pin (ex Physical # starts with a 1, internal starts with a 0, then gnd/voltage lines don't have GPIO #s.

OSD BUTTON -> GPIO13 or GPIO_1[10] or PIN_AG25
USER BUTTON -> GPIO15 or GPIO_1[12] or PIN_AH24
RESET BUTTON -> GPIO17 or GPIO_1[14] or PIN_AG23

Then the pin associated with the Cyclone 5 is the PIN_AXX, which is what is needed for FPGA cores to know what pin the FPGA will reference/assign.

I hope this clarifies things a little bit...

[jca]

I already understood this from the start. This is not my question.
The exact terms GPIO13, GPIO15 and GPIO17 have been mentioned (forget about the other denominations).
Here is what @arago mentioned in the first post:
" Where is the code that references GPIO17 and reads it. If there are more than one place, which one is critical for booting up?
Why are GPIO13/15 referenced like this? That could help me to understand the code better [gpi >> 29) & 3]
Is there some kind of check that reads GPIO17 to evaluate the status of the board?
"
The question is where these exact terms have been used?

[jca]

As no one seems to understand what I am talking about I re-read @arago first post and here are the mentions of these pins in his own post.

DE10 Nano has shorted GPIO17 (Reset), confirmed via multimeter
the DE10 Nano had a short between GPIO Pin 13
all 36 GPIO1 pins (D0-D35)
the GPIO1 Pin 17 (RESET) is shorted
these are ignoring GPIO17
Where is the code that references GPIO17
Why are GPIO13/15 referenced
that reads GPIO17

It looks like @arago made up these pin names himself. Sometimes he mentions GPIO-1 pin 17 and other times GPIO17 (as a shortcut I suppose).
This really confused me and though GPIO17 was mentioned in some other document.

[arago]

I now understand what you meant before. Yeah, it was my fault. I used GPIO17 as an abbreviation of GPIO-1 Pin 17. Sorry for the confusion, I will try to start using the correct terminology from now on. I don't think I have seen such abbreviation used anywhere else in the forum or the documentation.

[jca]

No problem. It was just driving me crazy as I did not make the connection so to speak. May be I am a little too technical and did not read between the lines: if someone says GPIO17 there must be a document somewhere mentioning it and I will be looking for this document forever.
That said these pins can be troublesome when you start FPGA. When I first started I studied existing projects (not MISTer but still Altera/Intel from Terasic) and I had to figure out which pins were used. If it was for MISTer for example and I want to know where BTN_RESET goes I won't find it in the Tersasic documentation as generic names are used. Without experience it took me some time (not too long) to find the pin assignment window where I would find BTN_RESET going to PIN_AG23 and the documentation says PIN_AG23 is GPIO_1[14] which is Pin 17 on connector J7.

[arago]

Sharing here the recompiled files disabling buttons and swapping reset for other people that might be experiencing the same issues. This includes Menu, Main, and console/arcade cores:

DisabledButtons+ResetSwap.zip

(28.33 MiB) Downloaded 275 times