Blank Display, Hardware Fault

[j0n5m1th]

The display can go blank when using a USB device like a CANivore. All status LEDs are solid on (specifically status, solid red), implying some hardware fault. The display will stay off and the status LED will show solid red after a power cycle.

Hardware configuration:

• SystemCore is powered the same way we would wire a roborio (follows R615.B)
• CANivore plugged into USB 0, no other USB devices
• CANivore wired for redundant power as described in the user guide
• "can_s0" effectively used as the "rio" bus which contains a mix of devices from various vendors
• Ethernet plugged directly into the "rio" port on the VH-109 (POE wires removed, follows R703.B)

System configuration:

• installed CANivore native packages declared in the CTR-Phoenix doc
• all CTRE devices on the available 2027 firmware
• all other devices on the system CAN bus are the latest 2025 versions

Software:

• project generated from 2027 WPILib VSCode and another 2025 ported project
• CTRE devices used on both the CANivore and s0 busses
• all non-CTRE devices are not referenced in code

We haven't been able to trace the issue yet (still fresh), but it does seem to be reproducible.

It's also worth noting that the robot did behave appropriately when enabled, so devices were still functional even though the display was not.

[jwbonner]

We've seen symptoms with some similarities, unclear if it's the same root cause. This is with a SystemCore powered from a 12V/5A DC power supply and nothing else connected (except the link USB, attached well after booting).

• When the display was working, there were occasionally times that the spinning icon in the corner of the display (the heartbeat indicator?) would freeze for several minutes at a time and come back. There's not a lot of documentation about what that indicator is supposed to show, but I thought I'd mention it because it seems suspicious.
• After several hours of testing, the display no longer displays anything at all and the red status LED is solid. This is consistent even after rebooting and/or reflashing the device. It otherwise appears to still be functional and is accessible over the network. I don't see any obvious problems poking around the console either (the RT subsystem is visible over USB and the Pico flasher service doesn't have any errors).

[bhjelstrom]

It is safe to continue testing for now. This is isolated to the OLED display module, so nothing else should be affected. We do not think this is related to the USB subsystem. We will reach out soon about new shipments for boards or Systemcores so we can swap units and root-cause the issue. We're doing a few tests here first.

The one unique thing about this batch of displays is that they all went through a hotbar rework. It's possible that something went wrong during this process for some of the boards. We haven't had a post-installation display fault yet, so this is a good thing to catch and root-cause now. The hotbar process is likely being eliminated in favor of an FPC connector for future batches.

The two spinning display indicators serve as heartbeat indicators for the two cores on the RP2350. The display runs on the second core.

Changes:

• The datasheet at the original link has been updated with display fault information
• The firmware has been updated with a 2Hz red blink pattern for display faults to make display faults easier to catch (set for release 158)

@j0n5m1th Does your display re-enable after powercycling?

[j0n5m1th]

I'm pretty sure a power cycle does not re-enable the display.

At one point, we reflashed SystemCore and the screen became functional again.

I've got a student that should be able to dig into this a bit more this afternoon.

[j0n5m1th]

tldr; We tried to reproduce inadvertently disabling the display, but failed to do so. Re-flashing SystemCore was sufficient to re-enable the display and we could not disable the display or fault status (despite experiencing the issue yesterday).

Steps from today's efforts to reproduce the issue.

Screen was disabled (state from yesterday)

• Power cycle
• DFU bootup
• Power cycle
• Deploy blank project
• Power cycle
• Deploy working project
• Power cycle
• Run gradle script to kill robot process
• Power cycle
• Uninstall CANivore driver
• Power cycle
• Unplug CANivore
• Power cycle
• Remove ALL other wires including ethernet
• Power cycle
• Reflash unit with ethernet connected (no USB)
• Power cycle
• Reflash unit, (with only power wires connected)
• Many power cycles, the display is now re-enabled (each previous step the display was disabled), (one power cycle the screen displayed mangled text)

With a functional display:

• plugged back in all devices (ex. Ethernet, CANivore, can_s0)
• power cycle
• install CANivore native packages
• power cycle
• set team number
• power cycle
• push blank code project
• power cycle
• reference one CTRE device on CANivore
• power cycle
• push working robot code (from yesterday when the display was disabled)
• power cycle

At all times the display was functional. We went through this same general processultiple times.

Grasping at straws, we tried to see if the CTRE vendordep from yesterday was a contributing factor (systemcore instead of linuxsystemcore platform). After a Gradle clean and pulling the "day old" vendordep, the display still functioned. We then tried to do this on a freshly flashed SystemCore to get a clean slate and the display was still enabled.
We also let the system idle for a while and the display remained functional.

[kevinwang]

A similar thing just happened to our unit at about 2.5 hours of uptime. The display started glitching out and after a power cycle, blank display and 3 solid LEDs.

IMG_3723.mov

[bhjelstrom]

@j0n5m1th Thanks for all of your effort in attempting to reproduce this. There are some good hints here based on the fact that your display seemingly came back to life.
@kevinwang This video helps. We are going to see what comes of the next few days of investigation into this before deciding what to ship to you.

Update:

• Jonah's replacement has landed, so we will be able to receive his old one and probe the display soon.
• The full display board schematic and everything posted here has been sent to the display manufacturer.
• A few units have been left to run continuously for a few days (we've already done several tests like this, however).

[j0n5m1th]

One more nugget:

1. Our first boot up yesterday, SystemCore had no signs of life (no LED indicators, screen, ethernet, devices not initialized), waited 3 minutes:

2. Power cycle: Display on, mangled text / frozen heartbeat

CCSVID_20250625_145651447.mp4

3. Power cycle: Display on, systems OK

We haven't been able to reproduce the behavior in the first item.
We've seen mangled text / frozen heartbeat a few times.

We'll keep an eye on this as we shift our focus.

[EthyMoney]

We (4607) encountered this display failure on our unit as well. It was working totally fine the first night I powered it up and was working with it. I left it powered up all night and throughout the next day while I was at work, and came home to the display frozen like this:

I power cycled the unit and the display has not come back on and the red fault light is flashing (alpha 2 OS, 159)

Not knowing any better, I'm tempted to speculate that the long-term heat of running for over a day may have contributed to the failure of the display/connection, but that's just a thought to throw out there. The display quit working within the first 24hrs of being powered on.

Other than the display failure and hardware fault light now being on, the rest still works normally and I can open the web interface and connect and deploy code just fine yet, so that's good!

[j0n5m1th]

@bhjelstrom

We lost the display again after a cold boot last weekend. We haven't been able to get it to re-enable. No measure of flashing, power cycling, code deploys, etc. seem to have an effect.

The good news is that the latest OS image does show the expected blink pattern:

Like Jonah, do you want this one back to investigate? We're hoping to run SystemCore at IRI next week & share with teams.

[bhjelstrom]

Alpha 3 addresses this issue.

We were driving the display with about 2x the current we originally thought. This was still barely within spec, but it completely eliminated our safety margin.

Alpha 3 addresses this in a few ways:

• Reduce display current by 80%. The screen will not be as bright. Let us know if the new brightness level is a problem
• The display will automatically dim and shut down after 10 seconds of no-motion.
• The display will turn on again if you tap your Systemcore.

@j0n5m1th Yes, we can swap units with you today.
@kevinwang @EthyMoney We can swap with you when you're ready as well.
@EthyMoney We can send a display module if this is preferred (I believe you are already familiar with the assembly process)

Thanks for everyone's patience as we worked through this.

[EthyMoney]

Alpha 3 addresses this issue.

We were driving the display with about 2x the current we originally thought. This was still barely within spec, but it completely eliminated our safety margin.

Alpha 3 addresses this in a few ways:

* Reduce display current by 80%. The screen will not be as bright. Let us know if the new brightness level is a problem

* The display will automatically dim and shut down after 10 seconds of no-motion.

* The display will turn on again if you tap your Systemcore.

@j0n5m1th Yes, we can swap units with you today. @kevinwang @EthyMoney We can swap with you when you're ready as well. @EthyMoney We can send a display module if this is preferred (I believe you are already familiar with the assembly process)

Thanks for everyone's patience as we worked through this.

Great to hear, now the team can stop joking that it died because I touched it lol

You're correct, we're definitely familiar with getting into it already. Feel free to send us just the display module and we can easily swap it out.

Thanks for the update, looking forward to more testing!

[bhjelstrom]

Release 161 is stable