I think a good idea at this point would be to carefully check the voltage of each of the power/gnd pins on the CS4237B while the system is running.
If you can compare against a working setup on the TinyLlama, that's even better. If nothing seems wrong, then perhaps try to look at signals going into the CS, preferable with an oscilloscope.

snipe3687 wrote on 2024-05-10, 12:53:

I did power on the board with the chip removed to see if anything in the POST or BIOS changed because one thing I noticed before in the BIOS that the setting to enable the external synth module is disabled and greyed out. Same thing with the chip out of the board so that leads me to believe the BIOS is not reading the CS4237b to be able to toggle. I would assume you could do that even without an external synth since I don't have one and my understanding is it's just a chip select line that is being enabled. It also helped me verify that the "CS4237b initialized" message is a static string of text and doesn't actually tell me that anything is really initialized like the PWM fan controller does. (if I'm wrong let me know!)

Correct, there's not really a check to see if the CS4237B is present or not. The grayed out external FM synth option relies on a simple Adlib check, which obviously won't work in any case if the chip isn't running correctly.

snipe3687 wrote on 2024-05-10, 12:53:

Is it possible it's stuck in reset somehow? I see the reset line goes to U2 which connects the reset line between the SOM, CS4237b and the PCIe to PCI bridge chip but I didn't think much of that since the bridge chip is working

Could be, just check if the voltage on RSTDRV is high (reset active) or low. U2 is an inverter, the /PCIE_RST signal is coming from the SOM and is active-low.

snipe3687 wrote on 2024-05-10, 12:53:

Also, Eivind, do you have gerbers for the OPL3 module somewhere? I'd love to build one of those too! I already bought the chips based on studying your images 😀

The designs/gerbers for the OPL3 modules are integrated into an earlier revision of the ITX board, but I'll see if I can extract that and make a separate Kicad project.

Eivind, thanks for adding the source to the firmwares to the GitHub repo! The only thing missing now is the source for the BIOS. Any chance we could get our hands on that as well?

valterb wrote on 2024-05-10, 14:04:

Eivind, thanks for adding the source to the firmwares to the GitHub repo! The only thing missing now is the source for the BIOS. Any chance we could get our hands on that as well?

Yes, of course! I'll have to do a tiny bit of cleanup first, but I'll add it as well!

Eivind wrote on 2024-05-10, 15:02:

Yes, of course! I'll have to do a tiny bit of cleanup first, but I'll add it as well!

Awesome. Thanks a ton for everything.

Eivind wrote on 2024-05-10, 14:00:

The designs/gerbers for the OPL3 modules are integrated into an earlier revision of the ITX board, but I'll see if I can extract that and make a separate Kicad project.

Awesome! I did see that you had a panelized board with some on it. Honestly, if it's too much trouble would it be possible to just send the project as is and I can try to extract it or just make a new one? really what I need to know is where things need to go.

thanks again!

snipe3687 wrote on 2024-05-10, 17:19:

Awesome! I did see that you had a panelized board with some on it. Honestly, if it's too much trouble would it be possible to just send the project as is and I can try to extract it or just make a new one? really what I need to know is where things need to go.

Added a kicad subproject to github with 6 opl3 modules panelized that I had ready. Should be simple enough to reduce that down to just one or two yourself if you wish!

UPDATE:

I spent about 3 hours last night going over EVERYTHING again on the sound card. checked all the passives, they are all the correct values. Traced all the address lines and data lines back to the SOM header, no problem there. checked all the voltage points on the chip. all have 5v and 3.3v where they should. Replaced the crystal, U2, U16 and remove the synth header. Removed the audio jack header, disconnected the chip from everything that wasn't required for the chip to be detected like the PI, wavetable, S/PDIF, etc.

I checked all the voltages and cross-referenced them with the voltages on my working TinyLlama. everything looks the same EXCEPT address line 5 (A5) is reading 3.3 volts on the ITX but 0.1 on the TL which all the other pins aside from D5 are reading on the ITX.
I noticed when you first turn on the board that all the address lines go up to 3.3v and then down to 0.1v or so which I'm guessing is the start up cycle because the TL does that too.

I lifted the pin on A5 and checked the voltage and it was still 3.3v which tells me the voltage is coming from the SOM. I checked the other pins on the SOM and they are 0.1v so they are likely getting the signal from the CS4237 at that point. oddly, I lifted the A5 pin on the SOM side, verified there was no continuity between the pad and pin and even put a piece of tape under it so the trace is effectively inactive but I still see 1.5v on the trace AND the SOM header pin that goes into the SOM. Normally this would tell me that there is a bridge somewhere but I am not finding continuity from that pin to anywhere on the board so far. Maybe it's picking it up through an electical field or something? IDK that's pretty far fetched I'm sure.

That has to be the problem right? A5 is one of the main address lines. Also, I'm seeing that voltage on the SOM pin with the SOM removed so I have no idea what's happening anymore. everything like, EVERYTHING else checks fine. I reflashed the BIOS as well but didn't expect much from that.

I can provide pictures if necessary but i'm almost completely out of ideas here. Is there anyway to debug the SOM and see what that pin is doing and what data is on it? or even the CS4237?

HELP!

snipe3687 wrote on 2024-05-11, 12:58:

UPDATE: […]
Show full quote

UPDATE:

I spent about 3 hours last night going over EVERYTHING again on the sound card. checked all the passives, they are all the correct values. Traced all the address lines and data lines back to the SOM header, no problem there. checked all the voltage points on the chip. all have 5v and 3.3v where they should. Replaced the crystal, U2, U16 and remove the synth header. Removed the audio jack header, disconnected the chip from everything that wasn't required for the chip to be detected like the PI, wavetable, S/PDIF, etc.

I checked all the voltages and cross-referenced them with the voltages on my working TinyLlama. everything looks the same EXCEPT address line 5 (A5) is reading 3.3 volts on the ITX but 0.1 on the TL which all the other pins aside from D5 are reading on the ITX.
I noticed when you first turn on the board that all the address lines go up to 3.3v and then down to 0.1v or so which I'm guessing is the start up cycle because the TL does that too.

I lifted the pin on A5 and checked the voltage and it was still 3.3v which tells me the voltage is coming from the SOM. I checked the other pins on the SOM and they are 0.1v so they are likely getting the signal from the CS4237 at that point. oddly, I lifted the A5 pin on the SOM side, verified there was no continuity between the pad and pin and even put a piece of tape under it so the trace is effectively inactive but I still see 1.5v on the trace AND the SOM header pin that goes into the SOM. Normally this would tell me that there is a bridge somewhere but I am not finding continuity from that pin to anywhere on the board so far. Maybe it's picking it up through an electical field or something? IDK that's pretty far fetched I'm sure.

That has to be the problem right? A5 is one of the main address lines. Also, I'm seeing that voltage on the SOM pin with the SOM removed so I have no idea what's happening anymore. everything like, EVERYTHING else checks fine. I reflashed the BIOS as well but didn't expect much from that.

I can provide pictures if necessary but i'm almost completely out of ideas here. Is there anyway to debug the SOM and see what that pin is doing and what data is on it? or even the CS4237?

HELP!

Let's get a couple of things out the way. First - just so I'm 100% sure, you're talking about this trace, right?

Second, are you using a scope or a simple voltmeter for the readings? If it's the latter, it can be hard to know what's really going on, as any activity pulling a line up or down will only move the average voltage read by a voltmeter to one or the other direction - how much will depend on the amount of time the line is high or low. As an example, a scope reading of a steady 1.5v is very different from a real signal spending roughly half the time at 0v and 3.3v, which will also be read as 1.5v by a voltmeter.

When you lifted the pins off the pad and saw 1.5v on the trace, I'm thinking that a thin trace not connected to anything else, sandwiched between other lines with a voltage potential can absolutely be affected by those.

Again, I feel much of our ability to diagnose this further rests on whether you have an oscilloscope or not. If you do, you can use it to measure the voltage of A5 coming from the SOM against ground, and manually trigger it from DOS using the DEBUG program. Type "i 20" for instance, for an I/O read of address 0x20 - which is 00 0010 0000 in 10-bit binary. The 1 in that number corresponds to A5. Observe that you're getting a reading on the scope. You can cross reference that with "i 10" which will make A4 go high for a split second.

Here's my last thought - could it be that the pin on the SOM pin header doesn't make a proper connection with the female receptacle metal part on the underside of the SOM? Check that carefully - I've experienced slightly bent metal "clips" on those receptacles after having janked the SOM off many times, and have had to poke them ever so much with a thin tweezer or needle to get them back in alignment.

Don't worry, we'll get there - happy to help! 😁

Eivind wrote on 2024-05-11, 14:16:

Let's get a couple of things out the way. First - just so I'm 100% sure, you're talking about this trace, right? Screenshot 2024 […]
Show full quote

snipe3687 wrote on 2024-05-11, 12:58:

UPDATE: […]
Show full quote

UPDATE:

I spent about 3 hours last night going over EVERYTHING again on the sound card. checked all the passives, they are all the correct values. Traced all the address lines and data lines back to the SOM header, no problem there. checked all the voltage points on the chip. all have 5v and 3.3v where they should. Replaced the crystal, U2, U16 and remove the synth header. Removed the audio jack header, disconnected the chip from everything that wasn't required for the chip to be detected like the PI, wavetable, S/PDIF, etc.

I checked all the voltages and cross-referenced them with the voltages on my working TinyLlama. everything looks the same EXCEPT address line 5 (A5) is reading 3.3 volts on the ITX but 0.1 on the TL which all the other pins aside from D5 are reading on the ITX.
I noticed when you first turn on the board that all the address lines go up to 3.3v and then down to 0.1v or so which I'm guessing is the start up cycle because the TL does that too.

I lifted the pin on A5 and checked the voltage and it was still 3.3v which tells me the voltage is coming from the SOM. I checked the other pins on the SOM and they are 0.1v so they are likely getting the signal from the CS4237 at that point. oddly, I lifted the A5 pin on the SOM side, verified there was no continuity between the pad and pin and even put a piece of tape under it so the trace is effectively inactive but I still see 1.5v on the trace AND the SOM header pin that goes into the SOM. Normally this would tell me that there is a bridge somewhere but I am not finding continuity from that pin to anywhere on the board so far. Maybe it's picking it up through an electical field or something? IDK that's pretty far fetched I'm sure.

That has to be the problem right? A5 is one of the main address lines. Also, I'm seeing that voltage on the SOM pin with the SOM removed so I have no idea what's happening anymore. everything like, EVERYTHING else checks fine. I reflashed the BIOS as well but didn't expect much from that.

I can provide pictures if necessary but i'm almost completely out of ideas here. Is there anyway to debug the SOM and see what that pin is doing and what data is on it? or even the CS4237?

HELP!

Let's get a couple of things out the way. First - just so I'm 100% sure, you're talking about this trace, right?
Screenshot 2024-05-11 at 15.28.28.png

Second, are you using a scope or a simple voltmeter for the readings? If it's the latter, it can be hard to know what's really going on, as any activity pulling a line up or down will only move the average voltage read by a voltmeter to one or the other direction - how much will depend on the amount of time the line is high or low. As an example, a scope reading of a steady 1.5v is very different from a real signal spending roughly half the time at 0v and 3.3v, which will also be read as 1.5v by a voltmeter.

When you lifted the pins off the pad and saw 1.5v on the trace, I'm thinking that a thin trace not connected to anything else, sandwiched between other lines with a voltage potential can absolutely be affected by those.

Again, I feel much of our ability to diagnose this further rests on whether you have an oscilloscope or not. If you do, you can use it to measure the voltage of A5 coming from the SOM against ground, and manually trigger it from DOS using the DEBUG program. Type "i 20" for instance, for an I/O read of address 0x20 - which is 00 0010 0000 in 10-bit binary. The 1 in that number corresponds to A5. Observe that you're getting a reading on the scope. You can cross reference that with "i 10" which will make A4 go high for a split second.

Here's my last thought - could it be that the pin on the SOM pin header doesn't make a proper connection with the female receptacle metal part on the underside of the SOM? Check that carefully - I've experienced slightly bent metal "clips" on those receptacles after having janked the SOM off many times, and have had to poke them ever so much with a thin tweezer or needle to get them back in alignment.

Don't worry, we'll get there - happy to help! 😁

Ok SUCCESS!

I reattached the pins and checked everything with the scope which looked fine. As I was probing around the crystal seemed loose still so I decided to take it off again, attach some leads to it and reattach to the board to see if maybe it wasn't getting enough solder or something. I powered on and went right into debugging as you said to do and realized I didn't have the debug.com program on my SD card so I powered off and copied it over. When I powered back on I noticed that unisound detected the chip which made me do a double take as I didn't expect that. I must have missed it the first time!
One thing I noticed is that the crystal this time was in a different orientation, essentially rotated 180 degrees. My understanding is that crystals aren't polarized since they use piezoelectric vibration but just to be safe I put a new one on but in the opposite orientation and tinned the pads first before I attached it just to make sure that it made good contact.
I also noticed one of the capacitors connected to the crystal was cracked so I replaced that as well. I suppose it's possible it's been cracked the whole time and maybe THAT was the problem but at this point it's all speculation.
I reassembled everything and tested. EVERYTHING is now working!

the ONLY little quirk I still see is, when I first power on and it makes the sound during POST, there is a static crackling for about 2-3 seconds directly after. it almost sounds like a capacitor charging up or something. it doesn't do it when I do a warm reboot just a cold one.

I can check the RFILT and LFILT again as I think those are related to aliasing on the line out signal but I'm just happy it's finally working!
Installed windows 98 and everything works there too so it seems I'm finally over the hump. now I can get started on the second board which are usually much cleaner for me since I've already worked out all the kinks on the first one.

if you guys have any suggestion on where to look for that static issue please let me know but in the meantime THANK YOU SO MUCH for all the help!

on inspecting everything again it looks like C70 and C71 are installed 90 degrees rotated from where they should be. For the whole board I basically just matched the orientation of the text designator for the piece and the piece itself which has apparently failed me in this instance. I'm sure this is where the issue is coming from since both positives on the MIC inputs are connected together. but I'll let you know when I have time to try it later.

The other MINOR thing is that I flashed the RP2040 after compiling the UF2 file, something I've never done before but it doesn't seem that windows is detecting that device. maybe I'm misunderstanding how it's supposed to function, but I suppose it's also possible that I didn't compile the firmware correctly or that there's some other problem.

Let me know if you have any ideas on that one.

snipe3687 wrote on 2024-05-12, 12:35:

I also noticed one of the capacitors connected to the crystal was cracked so I replaced that as well. I suppose it's possible it's been cracked the whole time and maybe THAT was the problem but at this point it's all speculation.
I reassembled everything and tested. EVERYTHING is now working!

Yeah, that might very well have been it. With wrong capacitor values for the crystal it might not have started oscillating.

snipe3687 wrote on 2024-05-12, 20:49:

The other MINOR thing is that I flashed the RP2040 after compiling the UF2 file, something I've never done before but it doesn't seem that windows is detecting that device. maybe I'm misunderstanding how it's supposed to function, but I suppose it's also possible that I didn't compile the firmware correctly or that there's some other problem.

I need a bit more info here, not sure I understand what the problem is.
Here's how you do it:
1. Compile the rp2040 firmware using the pico-sdk resulting in a uf2 file
2. Remove the jumper from J19 "HID_POWER"
3. Connect a USB A-A cable (or A-microB -> some adapter back to A or C) between one of the USB_HID ports and a modern computer while holding down the SW3 button
4. A mass storage device should show up on the computer, copy the uf2 file over to it (it'll update the firmware automatically and the MSD will disappear)
5. Remove the cable and reattach the J19 jumper
6. PS/2 through the USB_HID ports should work

Eivind wrote on 2024-05-13, 06:19:

Yeah, that might very well have been it. With wrong capacitor values for the crystal it might not have started oscillating. […]
Show full quote

snipe3687 wrote on 2024-05-12, 12:35:

I also noticed one of the capacitors connected to the crystal was cracked so I replaced that as well. I suppose it's possible it's been cracked the whole time and maybe THAT was the problem but at this point it's all speculation.
I reassembled everything and tested. EVERYTHING is now working!

Yeah, that might very well have been it. With wrong capacitor values for the crystal it might not have started oscillating.

snipe3687 wrote on 2024-05-12, 20:49:

The other MINOR thing is that I flashed the RP2040 after compiling the UF2 file, something I've never done before but it doesn't seem that windows is detecting that device. maybe I'm misunderstanding how it's supposed to function, but I suppose it's also possible that I didn't compile the firmware correctly or that there's some other problem.

I need a bit more info here, not sure I understand what the problem is.
Here's how you do it:
1. Compile the rp2040 firmware using the pico-sdk resulting in a uf2 file
2. Remove the jumper from J19 "HID_POWER"
3. Connect a USB A-A cable (or A-microB -> some adapter back to A or C) between one of the USB_HID ports and a modern computer while holding down the SW3 button
4. A mass storage device should show up on the computer, copy the uf2 file over to it (it'll update the firmware automatically and the MSD will disappear)
5. Remove the cable and reattach the J19 jumper
6. PS/2 through the USB_HID ports should work

Hi Eivind,
Once again I very much appreciate you helping a noob like me. Hopefully I can in turn use some of what I learn to help someone else down the road.

Quick update on the other minor issue with the static, yeah I'm a dummy sometimes, I put to caps on 90 degrees from where they should be and rotating them back to where they're supposed to be fixed that issue.

For the RP2040,
I see now what you're saying, it's basically the same principal as the CH559 on the tinyllama, once flashed it should make USB devices appear as PS/2 to the system.
I flashed it the way you mentioned above a few days ago and it seems to have flashed correctly but when I connect a USB mouse to the port it doesn't do anything in windows. I checked the jumpers and made sure that the 2 for mouse were set to USB instead of PS/2 and I know the mouse works because it's detected and working on the native USB ports. I checked the signals on the MOSFETs for the mouse side and they seem to be correct. I haven't tried a keyboard yet, but I would think it shouldn't matter since the RP2040 is converting both to PS/2. I can test that later.

It's not a HUGE deal since I generally use PS/2 native most of the time anyway, but I will lose sleep knowing something isn't working perfectly 🤣. I can check all the passives again later but since I don't know exactly what I'm looking for signal wise and I do see signal on the MOSFETs I'm going to assume I'm just missing something silly.

snipe3687 wrote on 2024-05-13, 12:19:

Quick update on the other minor issue with the static, yeah I'm a dummy sometimes, I put to caps on 90 degrees from where they should be and rotating them back to where they're supposed to be fixed that issue.

That's great to hear! 🎉

snipe3687 wrote on 2024-05-13, 12:19:

I flashed it the way you mentioned above a few days ago and it seems to have flashed correctly but when I connect a USB mouse to the port it doesn't do anything in windows.

I'd start by connecting only a single USB keyboard to one of the HID ports and take it from there. Mice (and hubs) are generally trickier and there _can_ be incompatibilities.
If you want to try to debug the rp2040, there's the TTL serial (115200 bps, 8N1) J46 connector you can hook up to look at output from the firmware. You'd have to enable debug output in code and recompile another firmware first though.

Eivind wrote on 2024-05-13, 13:14:

That's great to hear! 🎉 […]
Show full quote

snipe3687 wrote on 2024-05-13, 12:19:

Quick update on the other minor issue with the static, yeah I'm a dummy sometimes, I put to caps on 90 degrees from where they should be and rotating them back to where they're supposed to be fixed that issue.

That's great to hear! 🎉

snipe3687 wrote on 2024-05-13, 12:19:

I flashed it the way you mentioned above a few days ago and it seems to have flashed correctly but when I connect a USB mouse to the port it doesn't do anything in windows.

I'd start by connecting only a single USB keyboard to one of the HID ports and take it from there. Mice (and hubs) are generally trickier and there _can_ be incompatibilities.
If you want to try to debug the rp2040, there's the TTL serial (115200 bps, 8N1) J46 connector you can hook up to look at output from the firmware. You'd have to enable debug output in code and recompile another firmware first though.

ok great! I will test with just a keyboard later. Again, I don't really care too much about using a mouse through, but I just want to make sure it works.

This project has been super fun despite the issues. It's the first time I've soldered 0402 caps so it's certainly an accomplishment for me.

snipe3687 wrote on 2024-05-13, 12:19:

Quick update on the other minor issue with the static... I put to caps on 90 degrees from where they should be and rotating them back to where they're supposed to be fixed that issue.

90 degrees? Not 180?

AlaricD wrote on 2024-05-13, 15:23:

snipe3687 wrote on 2024-05-13, 12:19:

Quick update on the other minor issue with the static... I put to caps on 90 degrees from where they should be and rotating them back to where they're supposed to be fixed that issue.

90 degrees? Not 180?

Yeah, the labels for that area read left to right but the actual component is supposed to be installed 90 degrees from that writing. If I had been looking closely, I would have seen that they didn't line up with the lines on the board properly but there was well over 200 of those small 0402 components so I'm just happy that I only screwed up those 2 😀

snipe3687 wrote on 2024-05-13, 15:29:

AlaricD wrote on 2024-05-13, 15:23:

snipe3687 wrote on 2024-05-13, 12:19:

Quick update on the other minor issue with the static... I put to caps on 90 degrees from where they should be and rotating them back to where they're supposed to be fixed that issue.

90 degrees? Not 180?

Yeah, the labels for that area read left to right but the actual component is supposed to be installed 90 degrees from that writing. If I had been looking closely, I would have seen that they didn't line up with the lines on the board properly but there was well over 200 of those small 0402 components so I'm just happy that I only screwed up those 2 😀

100% agreed. Impressive that you did all those 0402s manually! You know that you can have JLCPCB assemble these for you when ordering the boards, right? 😉

Eivind wrote on 2024-05-13, 15:45:

snipe3687 wrote on 2024-05-13, 15:29:

AlaricD wrote on 2024-05-13, 15:23:

90 degrees? Not 180?

Yeah, the labels for that area read left to right but the actual component is supposed to be installed 90 degrees from that writing. If I had been looking closely, I would have seen that they didn't line up with the lines on the board properly but there was well over 200 of those small 0402 components so I'm just happy that I only screwed up those 2 😀

100% agreed. Impressive that you did all those 0402s manually! You know that you can have JLCPCB assemble these for you when ordering the boards, right? 😉

🤣 yeah but that's half the fun!

snipe3687 wrote:

Yeah, the labels for that area read left to right but the actual component is supposed to be installed 90 degrees from that writing. If I had been looking closely, I would have seen that they didn't line up with the lines on the board properly but there was well over 200 of those small 0402 components so I'm just happy that I only screwed up those 2 😀

Ahhh, I see now. You had one capacitor connected to two different capacitors' connection points.

AlaricD wrote on 2024-05-13, 21:10:

Eivind wrote on 2024-05-13, 15:45:

Yeah, the labels for that area read left to right but the actual component is supposed to be installed 90 degrees from that writing. If I had been looking closely, I would have seen that they didn't line up with the lines on the board properly but there was well over 200 of those small 0402 components so I'm just happy that I only screwed up those 2 😀

Ahhh, I see now. You had one capacitor connected to two different capacitors' connection points.

Yep! Half the battle of troubleshooting is finding my own mistakes 🤣