Less drastic steps first
With the ignition off but the device on, reboot the device through the Settings menu.
Set a timer for two minutes on your phone after it’s done booting to the startup screen and see if the
No Panda message goes away at the end of it.
Sometimes giving the device time to flash itself with the car off can work. If not, continue with the rest of this.
SSH into your device
See SSH for more information.
Navigate to the panda folder
Flash the panda (car should be off)
On newer code…
On older code…
pkill -f boardd; cd /data/openpilot/panda/board; make; reboot
Note: C2’s (comma two) built-in panda requires 12V over “OBD-C” (ie. USB-C).
Doing this a few times may unstick a panda that isn’t flashing properly.
This alternative command can be ran if flashing the panda via the standard process proves unsuccessful.
cd /data/openpilot/panda ; pkill -f boardd ; PYTHONPATH=.. python -c "from panda import Panda; Panda().flash()"
Checking panda connectivity
Run the command,
lsusb and look for a line like the following to see if the panda shows as a connected usb device:
Bus 001 Device 005: ID bbaa:ddcc
If you see that line among the five lines of output; good. Try the above recovery steps, but try harder.
If not, power down your c3 and wait at least 20 minutes for the power to fully drain. The panda should start on the next boot, perhaps into DFU mode, and connect.
Try at your desk
In some cases, the problem with your panda may be due to code that only runs when CAN traffic is present.
You can disconnect your C2 or C3 from your car and instead plug it into an appropriate alternative 12V power source (15W or more; C3 can also take 5V), so the panda can start and none of the CAN traffic-related code will run.
(You’ll need to ensure the power source is sufficient and being delivered through a USB-A to USB-C adapter. High power USB-C to USB-C will not work.)
Level 9000 recovery (GPIO)(ONLY USE FOR COMMA3)
If your comma three’s internal panda needs to be reflashed, and the other methods above do not work. Attempt the following
To fix the internal panda, run the following lines one at a time when connected to the device via SSH. You can ignore any output about the device resource being busy.
echo 124 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio124/direction echo 1 > /sys/class/gpio/gpio124/value echo 134 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio134/direction echo 1 > /sys/class/gpio/gpio134/value echo 124 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio124/direction echo 0 > /sys/class/gpio/gpio124/value
With these done you should see “STM Device in DFU mode” or something similar when you run
lsusb. If you do you should be able to run the recover.sh script in the panda folder. It may still be held in DFU after the flash, in which case run the following to get it out of DFU.
echo 124 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio124/direction echo 1 > /sys/class/gpio/gpio124/value echo 134 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio134/direction echo 0 > /sys/class/gpio/gpio134/value echo 124 > /sys/class/gpio/export echo "out" > /sys/class/gpio/gpio124/direction echo 0 > /sys/class/gpio/gpio124/value