Closed khari05 closed 4 months ago
After tracing the error, I think 0x02
means the ADV7180 did not reply to the power on request on the I2C bus. Are there any components you would recommend for me to check for issues?
You are correct, that error signals an issue in the initialization of one of the video ICs, in this case the 7180. Things to check:
Good luck debugging the issue, let me know if I can help
I really hope the IC isn't the issue since they are the main thing I had JLCPCB pick-and-place. I'll look at the contacts on the chip, and trace the power on signal tomorrow, and see if they could be the issue.
Could any of the resistors or capacitors surrounding the chip or components on the underside of the PCB be affecting only this chip? I attached a lot of them by hand with a soldering iron and it's my first time soldering this many surface mount components.
If it has been soldered by machines then the likelihood of a bad contact decreases dramatically. In that case I can' really think of anything obvious. Most power lines are shared between both video ICs (in particular IO Vdd), as well as I2C and Reset. If one works fine, so should the other, and your ADV 7393 is working fine according to the error message. Just in case, check the orientation of the adv7180, the white dot should be in the corner closest to the power jack. Check there's 3.3v and 0v in both pads of C22. Do the same for C24 and C8, they should carry 1.8V. If all this checks out, then either you have a bad IC or it's badly connected.
I went and probed around, and traced the board, and noticed that C26 is only reading 1V... I found that U6 and its capacitor, C41 are both reading 1V.
I'm not sure how the encoder chip is responding properly since one voltage regulator just isn't working
Hi,
U6 is the PLL power supply, shouldn't really affect the boot up of either the encoder of the decoder but perhaps the decoder is a bit more anal about it. Question now is what's failing, is it the regulator? Perhaps there something shorted somewhere in the board. If you have a spare just replace this regulator and measure voltages again.
Jose
Thanks for your reply! That's exactly what I am going to do. I'll have to double-check the TLV70018 datasheet to see if it is even capable of dropping to 1V without being a faulty unit
Update: it is not supposed to do that. I don't doubt that the unit is faulty
Note that if there is a short or a broken part somewhere in the rail, it may be pulling down the voltage to 1V. There's a bunch of bypass caps that connect the rail to ground directly, it could be one of these. Measure resistance between the output of the regulator and gnd, just in case.
I think I've figured out what's wrong. The enable lead of my regulator wasn't getting 5v, which lead me to figure out that it's not soldered properly... the 1V reading is likely just from the 1.5µA leakage current that it's rated for. Fixing this made the ADV7180 initialize correctly...
Now I have a new error:
Oled NOT detected
Error init::0x00|0x0A
I think this error means that there were either 5 NACK signals or it timed out twice
UPDATE: I checked the voltage regulators and after fixing them, it trips the fuse during power on.
When bypassing the fuse, I get garbage on my screen. Do you have any advice on selecting the right video modes? I know this project has much more testing with PAL hardware, so there might just be some NTSC specific bugs that haven't been documented yet
Hi there, the 0x0A seems to be an undetected Encoder but I think you had that figured out already.
It's a bit unclear what happened next. There was another issue with the regulators that you fixed? Bypassing the fuse could be dangerous, what type of fuse are you using? what specs? The board may generate a bit of a current rush when in first powers on, but it should go pretty low pretty quick (200ma or so).
Regarding NTSC signals, some people have tested the board extensively with NTSC gear in the US and there are no specific issues with this. The ICs support most standards (PAL, NTSC, SECAM) and have the ability to autodetect and configure themselves for the input signals.
What device are you trying to visualize with the c2c? is it composite or svideo? Remember there is a button to select the input, which defaults to composite. Also, the OLED screen should display information about the signal being transcoded and there's a green led that should be on when an input signal is locked.
I'm using a 6v 1.5A fuse, that I think is the same LCSC part number that you mentioned in #3. It seems to trip even if I pull the fuse bypass after it has initialized, which makes me suspect that I might not have soldered it very well and there could be resistance in the solder joint that is causing it to trip when all of the chips are active.
I tried connecting via composite to my NES, and tried S-Video with a camcorder. The NES outputs different refresh rates depending on which cartridge is being played, that's why I tested it with a camcorder as well.
I have the serial port open in minicom, so I see that it is getting a signal. Just not outputting anything useable by either my LCD TV or GBS-C upscaler.
Hi again,
I'm still unsure if you were able to solve the 0x0a encoder init error. I assume you did. In that case, what was the problem and how did you solve it?
About the fuse, the fact that you are having to bypass it indicates a potential problem with your board, either a short somewhere or a faulty part. It shouldn't just trip.
About the signal, one thing to have in mind is that the output will be identical in frequencies to the input. I've found that my tv was not able to sync to Commodore 64 15khz output, however OSSC had no problem. In general, GBS-C is known to work with C2C without any changes. Are you using the gbs control fw or the original? I haven't tested this in a while, perhaps newer versions do not work. I'll check this afternoon.
I recommend adding an OLED screen to the c2c to simplify the debugging.
I just remembered that gbs control was unable to sync to c2c out of the box. The coasting setup in the gbs firmware is too tight for the signal generated by the encoder in the c2c. How does the c2c->gbs output look like? Could you describe it?
The solution is pretty easy, you need to tweak with the coasting controls. I am not sure if the gbs UI allows you to do that though. Back in the day I remember I had to change the coasting constants in two lines of the code. I need to have a look again, I just don't remember the details. Do you think you could flash a new fw into your gbs if I send you a tweaked version?
The output I was getting to my VGA PC CRT monitor, from my GBS-C was somewhat green while the desynchronized grayscale output from the NES was somewhat overlaid.
I tested it with an LCD TV by plugging the output of the c2c64 directly into the component input of the TV. The TV is a low-end model from a decade ago, and was sometimes getting a grayscale variant of the desynced image I got from the GBS-C to my VGA CRT, so the TV could have been improperly showing data because of something in the TV.
Suspecting that it may have something to do with data traveling between the decoder and encoder, I tested the solder joints of RN1 and found at least one joint that isn't making contact. I will fix it then try it again. Thank you for all of your advice.
I have now (hopefully) fixed RN1. The fuse isn't tripping anymore either... I think the video encoder was consuming obscene amounts of energy trying to encode garbage into component.
Now, the output I'm getting seems somewhat less like a hardware issue:
https://github.com/jsanpe/c2c-64/assets/35894769/0947d976-b606-487d-8407-70c39986a111
This is the gameplay part of the title screen for the NTSC version of NES Tetris, running on original hardware. It still isn't syncing correctly, but it appears to be outputting some color information.
My LCD TV is also not syncing correctly, but it seems to only be displaying in grayscale, compared to the GBS-C, which is pushing some color information.
I'm still unsure if you were able to solve the 0x0a encoder init error. I assume you did. In that case, what was the problem and how did you solve it?
Yes, I traced in the code that 0x0A could be caused either by no reply from the encoder IC or a timeout for the last two commands. I checked the voltage between FB4 and GND, and read 0.8v. This low voltage seems to always mean leakage current from a disabled TLV70018. I found the solder joint on the EN pin of U3 was also somewhat loose, and I could trace the next issue (fuse) after that.
It seems like the decoder can initialize with a bad connection on U3 and the encoder can initialize with a bad connection on U6...
The fuse was likely caused by the video encoder consuming obscene amounts of energy trying to encode the floating inputs from the bad solder joint on RN1. That's my current theory at least.
Do you have any device other than the NES you could test the C2C with? GBS is going to have issues syncing with C2C without the hack I told you about. I think going to the component input of your tv may be an easier way to check if there are any other issues with your board. However, we need a device that your TV can sync to. The more modern the better. N64 for instance could be a good one to try if you have one.
If you could get ahold of an OSSC that would be the perfect way to test it. C2C was designed to pair with the ossc.
I'll try to locate my gbs to test the fix. There are two lines that need to be changed in the original fw. You will need to recompile and reflash it. But let me test it first.
I plugged in a Sony camcorder over S-Video and saw that the "Locked" value was showing Y. I was having an issue with F1 tripping, however. Deciding that it must be caused by solder joints between the decoder and encoder, I resoldered RN1 (again), and replaced F1.
I found that the sync issues were definitely caused by the encoder chip since the output was now clean, and syncing on both my GBS-C and LCD. This is what the output looks like now:
I was testing to see if only one color channel is having issues, and found that if I disconnect Pr, I got a clean signal.
This happens on both S-Video, and Composite, on both my GBS and LCD. I suspect there is either an issue near the red channel, or one of the solder joints on RN1 is not happy, if one of the pins carries data specifically in the red channel. I will check the datasheet soon and let you know if this is also caused by RN1.
EDIT: If I'm understanding the datasheet correctly, the 8 bits of each chroma and luma are transmitted on the same 8 pins. That means something else must be causing the noise on the red channel.
Hi there,
If the problem is limited to the red channel, I would first look at D1 and R4, which are directly connected to the Red channel output. Check if they are correctly soldered, and working correctly. Otherwise the issue could be in pad 26 of the ADV7393, perhaps it's not making good contact.
I suspect D1 is likely related to the issue. I will check it out on my oscilloscope soon and let you know what I find
AND AFTER HOURS AND HOURS OF TROUBLESHOOTING, I ATTACHED RN1 CORRECTLY...
I discovered that all of my issues were caused by RN1 still not being attached properly. Almost all the pins were connected except one specific pin. I should have probed the individual pins of that resistor array with my oscilloscope much much earlier. If I did, I would've traced this much faster. It works! This is my first major soldering project where I ordered a PCB that I didn't design myself. Quite the learning experience.
Over the course of this project, I figured out how to create color bars on the composite port of a raspberry pi zero so that I could have a consistent waveform when viewing the output signals on my analog oscilloscope.
Thank you for all of your help!
Well, you've shown a lot of determination and perseverance. I'm really happy you made it work, and I'm sure after so much frustration these past few weeks you are now feeling absolutely great. Congratulations!!
Is the c2c64 supposed to throw an error to the UART console when there isn't an OLED display attached?
I have an NTSC NES attached to the board and have tried both directly to an LCD TV and through a GBS-C scaler, and am getting no video output. I will test it with a cartridge that outputs at a different framerate tomorrow since that could have something to do with it.
When testing, I also noticed that the TLV70018 was getting fed 5V to step down to 1.8V, is this normal? The voltage regulators seem to be getting warm when powered on for a while.
I'll test it with a VHS player or a camcorder later and see if the NES console could be the issue...