Ideas for troubleshooting (rev. 1.2 won't boot) #16
Replies: 10 comments 3 replies
-
Hi Fryderyk, welcome to the Minimal 64. Unfortunately you seem to experience a rough start ;-) Given the fact that already a handful of fellow Minimalists have successfully build the board we should be able to get yours up and running. Thanks for providing all the valuable information. You already went through quite a lot of work. Given the fact that you have soldered a second board reproducing the very same failure mode and have also checked all ICs for ESD damage a systematic problem seems likely to me. From your description we can deduce that the VGA circuit is working - which is good since it allows us to collect some more info. After a reset the following things happen:
The very last step is clearly not reached by your board. But I suggest you also monitor the serial port after pressing reset. Does it show "READY."? If you have the possibility, it could be interesting to take a look at the control signals, let's say COL (pin 19 MSB), II (pin 21 LSB) or IC (pin 15 MSB). They should be active low. I have uploaded a file called "debug_rename_to_flash.bin" into "../Revision 1.2/FLASH Images/..". It contains the following instructions at address 0x0000. They are executed prior to the bootloader and will produce a visible output in the VRAM (a black and a white 8x8 pixel square). Please burn it to the SSD flash and check if you can see any visual output (maybe try it in the emulator first). #org 0x0000 LDI 0x00 STA 0xc30c These few check should give us some more info. In the meantime I'd suggest you check a couple of "systematic" things, too:
Good luck! |
Beta Was this translation helpful? Give feedback.
-
Hi Fryderyk,
again thanks for doing all the helpful testing. Must be frustrating 😔 Actually the voltage levels you have measured for COL, II, IC seem very odd to me. They should be active low. EDIT: II is active HIGH. They should be clean TTL signals. Clock should be 8Mhz. Some are active high others are active low as indicated in the schematic and not all of them switch all the time. It would be good if you could take a look at "clean" high and low levels. If your supply provides 4.9v which is okay, you should see at least 4.5v there... please also check if any IC gets hot or are inserted reversely.
Anyway, since you have seen the squares we have the proove that the CPU executes at least basic instructions, i.e. fetching instructions from flash, writing to VRAM. Did you press a key after seeing the squares. OS should start up as I have described.
I'll generate another test image where we move the "squares" to later in the boot process. It is tedious but this will give us an indication to where exactly things go wrong...
… Am 30.09.2023 um 23:08 schrieb Fryderyk Dziarmagowski ***@***.***>:
Hi Carsten!
Having the answer from the Chief Minimalist himself is such a great thing, I can't really describe how I am happy to read your helpful words!
As suggested, I burned the new image. Seems like it works as expected, I can see two little squares on the left side of the screen.
There is no output on the serial port. I used minicom and picocom with suggested parameters, but it seems to be calm. Since I didn't find the way to set the required 1 start bit, I am not sure, my test is valid. I might have try suggested software, but due to lack of compatible OS, I have to postpone this one (maybe using Wine)
I verified the signals, measured voltages are:
COL 3,6 V
II 0.5 V
IC 4,2 V
Seems like COL and IC are not active low. I guess, the voltages differ from TTL levels a bit, as they are changing constantly (2 MHz according to my oscilloscope)
Going to other checks:
the voltage provided by the serial-to-usb converter is 4.9 V (verified on a random 74HC), tried with external power supply too, there is no change in the behavior
the only HCT ist 74HCT132 (U57)
all resistor values are correct (measured before soldering) but you are absolutely right, confusing the 470/4.7k seems to be a potential pitfall ;-)
C6 has 200pf, having 200nf causes VGA circuit to malfunction (I made a quick test too)
using 39SF010A here labeled as 70-4C-PHE, should be same as you are using
the 39SF040 (70ns too) is used only for flash
I asked a colleague of mine to build another Minimal 64 using the PCB from the batch (of 5) I have. As he will be using ICs from other sources, there is a big chance, I can exclude quality problems with the PCB itself (this seems to be unlikely, optically the boards are top notch). All the ICs I use are from TI/Philips/STmicro. Just 74HC00 are "no names", but I've replaced them too (using TI ones now)
Thanks!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.
|
Beta Was this translation helpful? Give feedback.
-
So I have found over the years that visually inspecting solder joints is sometimes not sufficient. I have been in the scenario described, and the problem ended up being one or more solder joints did not flow well and thus the joint has a level of resistance that is interfering with things. While I was never able to identify which solder joint was the problem, this scenario has been fixed for me (sometimes) by going over each solder joint with the iron again and reflowing each joint, sometimes adding more solder if the amount looks low. The goal is to ensure the solder flows down into the through hole, and not just position itself on top of the pad as the second case might have some rosin residual actually creating a barrier between the solder and the pad. Ensuring the solder is flowed into the hole usually prevents this. Not saying that this is the cause of your woes, but I saw the "visually checking all soldered pins" remediation and had flashbacks to my prior projects where I thought that was sufficient too. Good luck! |
Beta Was this translation helpful? Give feedback.
-
Another path to explore is using a logic analyzer (something like this) at various points in the board to ensure things are happening. Oscilloscopes are good for looking at the shape of a signal, but a logic analyzer allows you to see the content of a signal. Things I would check is what data is actually being pulled from the ROM. I used this technique myself to find an issue on my Minimal 64 when building it where the wrong data was being produced because of a mistake I made (though the mistake was a software one as I was altering the OS). |
Beta Was this translation helpful? Give feedback.
-
Hi Fryderyk, now this failure seems very strange indeed. It must be something systematic as all 3 boards refuse to boot. But the latest failure mode seem to differ in a way. It is maybe best to stick with your board first. Let us not connect the PS/2 keyboard for further testing. The board has to boot on its own first. BTW, I have to correct myself. Previously I states that "II" was active LOW. Actually, it is active HIGH. ~IC and ~COL are active low. Have you taken a look at the TTL levels of (all) the contol signals? I have uploaded a second test image "debug2_rename_to_flash.bin" to the repo for you. For every byte the bootloader transfers from FLASH to RAM it gives you a visual feedback by writing 0xff contiguously into VRAM. Works like a treat on my end. Since you have successfully carried out the "two squares" test with your board, this will be the interesting next step to get more information on where exactly your board gets stuck. Good luck! |
Beta Was this translation helpful? Give feedback.
-
Update: I have just downloaded and burned the 1.2 debug2 SSD and CTRL images from the repo onto my Minimal 64 rev1.2 and got exactly the expected behavior. I have also, with the initial random garbage on the screen, unplugged and re-connected my PS/2 keyboard. Since it is powered by the 5V provided by the Minimal 64 (and ultimately either by a power supply or - as in my case - by the serial bread-out board), all I have seen was a slight flickering on my monitor when the connection was made (i. e. keyboard power-up) but no changing RAM content at all. All seem very stable here. This may suggest that your board might have a power problem and connecting the PS/2 makes things worse. Have you monitored the supply voltage of all ICs during operation? That is easy to measure since it is the upper right pin on all ICs (with the half-moon on the chip defining the "upper" side). How do you power your board? It might be helpful to monitor the supply current as well. Good luck! |
Beta Was this translation helpful? Give feedback.
-
Update 2: Just for the record I list the steps the Minimal 64 performs after reset:
***** M I N I M A L 6 4 *****
|
Beta Was this translation helpful? Give feedback.
-
Hi Carsten! Many thanks for the second image! Unfortunately I can't well describe what's happening on the screen... (I can see the |||| pattern filling up the screen and moving). It might be not necessary anymore! :-D I have 2 first boards up and running. I guess my solution is not correct, but it works for a reason I can't explain yet: After I saw the output on the screen, created by th 2nd debug image, I realized, that the only IC which is still not verified is the RAM chip. Thanks! |
Beta Was this translation helpful? Give feedback.
-
This was a long ride! After hours of searching, I found the reason for the strange behavior on my Minimal 64 board. It was the U49 (74HC32N). After replacing it, I no longer have to use the 74LS161 mentioned above. Would be interesting to understand it better: how can two 74HC32N can be that different? Basic logic tests made with TL866II + minipro didn't reveal any problems. But this is a topic for a different discussion. Thank for your time and help :-) I really appreciate it. |
Beta Was this translation helpful? Give feedback.
-
Glad to hear you didn't give up and congrats on finding this bad IC! U49 is right at the heart of the Minimal's timing signal generator. I think it is the propagation delay of that specific OR gate that could be interesting to take a look at. It should be ~5ns. There seems to be quite a couple of bad ICs out there - maybe manufactured with poor quality or due to ESD during handling. Since the Minimal is kind of maxed out, it is quite sensitive... Watch out for the Minimal 64x4 ;-) |
Beta Was this translation helpful? Give feedback.
-
I've completed the board but I have no luck booting it. After pressing "reset" button, the random pixels on the screen stay the same (very, very few change). The random pixel order changes when PS/2 keyboard is connected, but after pressing reset nothing really changes.
So far I've tried:
Based on the VGA displayed on the monitor, at least I can say, it's displaying the random garbage from RAM correctly ;-)
What other troubleshooting could be applied to the Minimal 64? Any recommendations?
Beta Was this translation helpful? Give feedback.
All reactions