Unfortunately the new revision had quite a few issues that I was not expecting. Revision 2 was largely a form-factor change, the circuitry was tested with the SBC style PCB in the first revision.
So what changed? Mostly that peripheral and most of the circuitry went on their own little PCBs and are connected via FFC to the mainboard which now has a much more reduced circuitry, that brings costs down for the mainboard and you only pay for the peripherals that you actually need, this also enabled a free positioning of the peripherals but more on that in the next update.
Back to the mainboard. When I powered it on with Ethernet attached I got no device showing up in the network unfortunately. When I attached the serial console I got at least a boot log so things were actually running but it seemed kind of flaky, I often didn't get a login prompt at the end of the boot process. At the time I was thinking I was having power issues but in retrospect I think this was just a bug in an older version of JetPack (the OS for the Jetson, a modified Ubuntu).
I turned to the schematics and realised that the pinout on the Ethernet FFC connector was shifted by one pin to the right...
The same happened to the USB which I tried next with an Ethernet dongle but had not luck either for the same reason, pins were offset.
I was really puzzled about how that happened until I realised that the tabs of the connector which carry no signal were on the same side as the actual data pins on the schematic. When I mirrored the pinout I just mirrored it and applied it to the connector again in reverse order. The issue was that I included the tabs in that process and assigned them a signal instead of the GND connection...
The eDP and HDMI connector pinout were fortunately all good, I took a bit more time on those and didn't rush them out in day like the other peripherals.
Unfortunately they didn't work either. At that point it got quite frustrating, I went from a 100% working revision to a 10% working revision.
I quadruple checked everything, first thing I found was that I missed the eDP hot plug signal, it got renamed in the whole moving process. This was quickly fixed with a bodge wire. At that point the Jetson tried to establish a connection with the display and did seem to communicate but always failed during the link training process which establishes certain ground rules with the display for how the connection will be handled. The equivalent to this in HDMI is the EDID readout with the addition here that there is also some negotiation about the amount of signal lanes to use and other timing related things.
I did not get any further with this unfortunately. I tried wrapping my FFC cable in copper foil to shield it. I used shorter DisplayPort cables. Nothing worked. I got contacted by a person from Nvidia that also already helped me before with design resources, so hopefully I will get some more insight there of what might be wrong. Again, the circuit did not change, its all the same.
HDMI was a similar situation, EDID read fails but fortunately the Jetson goes into a default resolution for the HDMI for some reason if it can't read the EDID and this gave me a picture! So that at least hints that its not an impedance issue introduced with the FFC cables.
Why does the EDID read fail? I do not know, I checked the circuitry surrounding the I2C signal level translation but could not find any issues introduced with the move.
It is interesting though that both fail at a similar stage, the EDID readout / link training.
I tried the actual eDP PCB which connects to the eDP panel instead of a DisplayPort display. Unfortunately no difference, here I get even a stranger behaviour, the Jetson does not boot at all. When I unplug it and reset it is booting fine again. Hot-pluging it 'works' it atleast doesn't crash the system and yields similar edid / link training error messages as with the eDP to DP PCB.
While I'm waiting for feedback from Nvidia I started mocking up the mechanical design ideas. Specifically the central mounting plate. More on that in the next update.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.