I bricked an AIOC, is there anyway to recover it?
Closed this issue · 8 comments
I had a few boards made following the PCBWay instructions, and I messed one of them up. I let the boot jumper get disconnected while it was flashing the initial FW load. It was about 50%. Now it will not boot to the bootloader or anything else. I thought the factory boot loader was in ROM, but shorting the boot pins doesn't let it boot the boot loader. Is there any other way to upload the aioc-fw-1.2.0.bin file? Possibly via the serial (SWD?) interface? Or another method for starting the factory boot loader? Or is this board toast?
Here's the output I see in dmesg on my linux box first block with no boot jumper. Second with.
`[Tue Jun 11 21:51:43 2024] usb 1-1: new full-speed USB device number 20 using xhci_hcd
[Tue Jun 11 21:51:43 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:51:43 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:51:43 2024] usb 1-1: new full-speed USB device number 21 using xhci_hcd
[Tue Jun 11 21:51:44 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:51:44 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:51:44 2024] usb usb1-port1: attempt power cycle
[Tue Jun 11 21:51:44 2024] usb 1-1: new full-speed USB device number 22 using xhci_hcd
[Tue Jun 11 21:51:44 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:51:44 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:51:45 2024] usb 1-1: device not accepting address 22, error -71
[Tue Jun 11 21:51:45 2024] usb 1-1: WARN: invalid context state for evaluate context command.
[Tue Jun 11 21:51:45 2024] usb 1-1: new full-speed USB device number 23 using xhci_hcd
[Tue Jun 11 21:51:45 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:51:45 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:51:45 2024] usb 1-1: device not accepting address 23, error -71
[Tue Jun 11 21:51:45 2024] usb 1-1: WARN: invalid context state for evaluate context command.
[Tue Jun 11 21:51:45 2024] usb usb1-port1: unable to enumerate USB device
[Tue Jun 11 21:54:01 2024] usb 1-1: new full-speed USB device number 24 using xhci_hcd
[Tue Jun 11 21:54:02 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:54:02 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:54:02 2024] usb 1-1: new full-speed USB device number 25 using xhci_hcd
[Tue Jun 11 21:54:02 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:54:02 2024] usb 1-1: device descriptor read/64, error -71
[Tue Jun 11 21:54:02 2024] usb usb1-port1: attempt power cycle
[Tue Jun 11 21:54:03 2024] usb 1-1: new full-speed USB device number 26 using xhci_hcd
[Tue Jun 11 21:54:03 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:54:03 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:54:03 2024] usb 1-1: device not accepting address 26, error -71
[Tue Jun 11 21:54:03 2024] usb 1-1: WARN: invalid context state for evaluate context command.
[Tue Jun 11 21:54:03 2024] usb 1-1: new full-speed USB device number 27 using xhci_hcd
[Tue Jun 11 21:54:03 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:54:04 2024] usb 1-1: Device not responding to setup address.
[Tue Jun 11 21:54:04 2024] usb 1-1: device not accepting address 27, error -71
[Tue Jun 11 21:54:04 2024] usb 1-1: WARN: invalid context state for evaluate context command.
[Tue Jun 11 21:54:04 2024] usb usb1-port1: unable to enumerate USB device
`
Thanks.
I've interrupted quite a few flashes and always been able to get back to the bootloader with the jumper.
It's my (limited) understanding that the bootloader is not overwritten during the normal flashing operation.
You could try doing a reset while plugged in bootloader mode. i.e. put in the boot jumper, plug the device in, then short 3rd and 5th pins (GND and RST) to reset.
I've interrupted quite a few flashes and always been able to get back to the bootloader with the jumper.
It's my (limited) understanding that the bootloader is not overwritten during the normal flashing operation.
You could try doing a reset while plugged in bootloader mode. i.e. put in the boot jumper, plug the device in, then short 3rd and 5th pins (GND and RST) to reset.
I've read several places that the factory boot loader is in ROM, and cannot be overwritten/changed. ie you can't get rid of it.
I tried the GND/RESET after connecting it. No difference. One thing I've not tried at this point is a different computer. Ive tried different cables and ports. Including port types. I don't think it's the computer or cable as I have done more since this one messed up.
Just tested with another computer. Same result. To verify the cable was good, I connected a USB-C M.2 storage adapter and was able to see the drive.
What PCBway instructions did you follow? I only support the official JLCPCB data published by me. Are you sure you have the correct part numbers assembled? Can you include a photo/Screenshot?
I agree with @legonigel, it's very hard to lock yourself out of the ROM bootloader (requires fiddling with the OPTION ROM or something). You can safely remove the bootloader jumper once the device has booted into it, so that is not the issue.
Are you shorting the correct pins for the bootloader?
Sorry, my bad. I was sleepy when I typed that. It was JLCPCB. PCBWay is the one many YouTubers advertise and I typed the wrong thing. I followed the instructions from the main page here.
The others I got all went perfect. I didn't think the jumper had to stay in, but I did leave it in. This one that broke on me failed the upload at the time the jumper came out. The erase went good, then was about 50% uploading the bin when it stopped. Maybe the uC is just defective on this one unit and the jumper coming out had nothing to do with it. It's not that big of a deal, just thought I'd ask to make sure I wasn't doing something obviously dumb. If there was a way to possibly recover it, I'd give it a try.
I've connected it to three different machines with two different known good cables, and it appears to alway fuss about power, so I'm thinking it's something on the USB side of things on the board.
I see.. There must be a different fault on the PCB, because the ROM bootloader should always be accessible using the jumper method.
Are you sure you are jumping the correct pins? When the microcontroller is completely empty it automatically jumps into the ROM bootloader (as far as I know) ignoring the BOOT0 jumper. The jumper is only needed at the moment you plug in the power and the microcontroller starts up. After that it can be removed (and has to be removed for the microcontroller to start the application).
If the PC is reporting an issue with the power of the USB device, there might be a short or something somewhere on the PCB.
Yes, I'm sure I had the correct pins. The outer two pins. I did all the other boards, and this one started. It was about 50% uploading the .bin after getting to 100% erasing. So it was working until the wire came out during programming. Anyway, I just wanted to make sure there wasn't some other way to do anything with it.
I'll go over the board with my microscope (yes, I have a microscope just for working on micro electronics). I do think something failed on this one board. It is possible when the jumper pulled out it shorted against something else and damaged the uC, but I didn't think it had. I'll close this ticket now as it seems to be a hardware failure/malfunction of some sort unique to this unit.
Thanks,
Craig
I am going to close this issue due to inactivity. Let me know if you need more help.