Usb-C malfunction with computer

[NicoleMaggard]

Hello,
I just had a question revolving around troubleshooting the pycubed when windows throws an error saying: "the last USB device connected to this computer malfunctioned and windows does not recognize it." The pycubed is still running operations normally when powered, but is failing to connect to the computer so we can update the code. We did happen to setup the bare bones of OTA on the device, so this may be a path forward, but we are struggling to make it so the code can be updated directly in memory as opposed to loading code onto an SD card and executing from there. Any help would be greatly appreciated. Thanks

[maholli]

Hey @NicoleMaggard

Luckily it's very very difficult to completely brick these boards, so I have no doubt we can get it responding to USB again.

1. Did you build this board or is it one of the heritage ones I built? Also, does the board have v4 on it, or does it say v5?
2. Is the on-board flash MRAM or NOR? (if it's not MRAM then its NOR).
3. Are you able to reach the bootloader? See step 4 of the Updating PyCubed page

This is just a shot in the dark, but if you have OTA commands working (specifically exec_cmd as described at the end of beep-sat advanced), then you could try erasing the filesystem. Obviously only do this if you're willing to lose everything stored in flash.

• Then your full exec_cmd might look like:

# default pass code + exec_cmd code + code to run
b'p\xba\xb8C'+b'\x96\xa2+b'import storage\nstorage.erase_filesystem()'

• Then be patient as the board erases the filesystem and creates a blank default PYCUBED drive. You'll then need to copy your files and libs back.

Let me know how that goes before we try the "nuclear" options.

Good luck!
Max

[NicoleMaggard]

Hi Max,
Thank you for the quick reply! We built this pycubed, and had installed MRAM on it. This version is V5. The MRAM has been finicky in the past, but the pycubed still connected to the computer/terminal. Occasionally we had to use the erase filesystem function as a fix for the system resisting normal operations. We are not certain, but we are leaning towards the USB port being damaged from too many insertions. We may try to replace the port on one of the afflicted satellites and see if this makes a difference. To answer your question about the bootloader: The unfortunate part, is that we have a saddle board on top of the pycubed which is blocking the reset button to enter bootloader mode. From my understanding, there is a through hole connection for the reset that we can jump to ground on the bottom of the board. We tried to do a double tap on the reset, and no matter what cadence it seemed too difficult to push into the bootloader mode.
Thanks!
-Nicole Maggard (Bronco Space)

[maholli]

Understood. I have zero issues with my MRAM boards theses days - which could be a result of the underlying MRAM improvements I made to circuitpython over the last couple years or just pure luck. If you're running a recent CP build, I'd say 7.x or better yet 8.x, and still have strange MRAM behavior please let me know so I can look into it.

Your approach towards double tapping the reset pad to ground is correct. In the classroom I'd usually just use a breadboard jumper wire. You can also enter the bootloader by setting RunMode through microcontroller.on_next_reset(run_mode: [RunMode]). This of course is only helpful if you can access the REPL or run it using OTA commands.

I agree, it sounds like it could be a USB connector issue. Try slowly wiggling it around to see if your computer notices any changes - that would at least confirm the issue.