geekhack
geekhack Projects => Making Stuff Together! => Topic started by: Blitzschnitzel on Tue, 03 March 2020, 16:53:11
-
Hi, I am developing a new board and, in the process, I have managed to brick two prototypes. Both boards worked well but broke while flashing a new firmware. I don’t know if that is the reason it broke, but for the first one I hit the reset button and pressed Flash before the reset was all done. For the second one I pressed reset and only then started the QMK Toolbox and flashed it. Windows now says “USB-device was not recognized” when I plug the board in. The strange thing is that I can still reset and flash the boards. But that doesn’t change that the boards are not responsive. The backlighting still works but I can’t toggle it on or off or change the brightness. So, I think the MCU is stuck and it is not just a communication problem.
Would perhaps flashing a new dfu bootloader help? I have never done that before. The construction uses a 32u4 and is pretty standard, so I would be surprised if it were a hardware issue. But if needed I could upload a schematic.
-
not actually bricked if you can still flash them.
something a miss in the firmware?
leds drawing too much current?
send us what you got layout & firmware wise and i'm sure some others along with me will chime in. just need a little more detail of the build.
- controller, pins, layout, firmware, #of leds, etc...
-
THX. So, I’ve just used my USB amp meter and the board draws 433mA and my motherboard seems to be very forgiving with out of spec current draws. The backlight is stuck at full brightness but the RGB backlight is off so I don't know how much current it draws. The schematic and firmware are linked below.
-
most usb won't let more than 500ma unless it's charging via usb3 or QC 2.0, QC 3.0
can you upload a ZIP of your firmware folder or your git clone?
-
thanks
-
Just did it while you were typing. ;)
-
yep. saw that.
is it based off of another firmware or from scratch?
-
I copy pasted a few bits here and there but it is mostly written from scratch. I think in both cases the last edits were made to the Keymap before it stoped working. The only thing not so standard is the 7 segment display, but the driver IC is passive and I would be surprised if that were the problem.
-
sounds like it is a software crash. i've heard the term bootloop thrown around a lot too, not quite sure what it means. I managed to recover a teensy2.0++ by combining the bootloader and firmware in the same file and flashing it over isp. this gets around the crash issue when regular usb flashing won't.
-
THX. So, I’ve just used my USB amp meter and the board draws 433mA and my motherboard seems to be very forgiving with out of spec current draws. The backlight is stuck at full brightness but the RGB backlight is off so I don't know how much current it draws. The schematic and firmware are linked below.
That’s almost the current allowed in a USB 2.0. Becareful you might damage the usb controller inside your computer.
-
sounds like it is a software crash. i've heard the term bootloop thrown around a lot too, not quite sure what it means. I managed to recover a teensy2.0++ by combining the bootloader and firmware in the same file and flashing it over isp. this gets around the crash issue when regular usb flashing won't.
Yeah that might be it! Is there a tutorial that you followed? Or do you know a search term on how to compine the DFU hex and your firmware into one file?
That’s almost the current allowed in a USB 2.0. Becareful you might damage the usb controller inside your computer.
Well, I only have USB3 ports so I should be good. Also, evey name brand manufacturer will include a overcurrent protection in their USB ports, so that the worst that can happen ist that the mainboard cuts the power to your keyboard.
-
Well, I only have USB3 ports so I should be good. Also, evey name brand manufacturer will include a overcurrent protection in their USB ports, so that the worst that can happen ist that the mainboard cuts the power to your keyboard.
They do, but it relies on the cable, not the port and you shouldn't rely on it.
That's exactly the problem with Type A to Type C cables, it draws so much power through the type A port that it overheats and melts the connector, usually between 2.4 and 2.7 amps.
Windows can detect it on 2.0 connections sometimes but only if you are plugged in direct, not through a port and even then, don't count on it. Apple has had problems with it, Google has had problems with it... Look up Benson Leung if you want to find more horror stories and words of warning, he's the Google engineer who had one melt and started investigating which cables were dangerous.
-
Yeah that might be it! Is there a tutorial that you followed? Or do you know a search term on how to compile the DFU hex and your firmware into one file?
If you use QMK, when you compile, you just need to add :production at the end of your command.
Example: make handwired/colorlice:default:production
This will compile a normal hex file, as well as _bootloader and _production hex files. The _production hex will be what you want. This contains the bootloader and the firmware, so you only nedd to flash once. (rather than flash the bootloader, and THEN flash the firmware).
Time to hook up your ISP Flasher, and do the magic trick.
-
I followed this guide, using a teensy2.0 to flash https://beta.docs.qmk.fm/for-makers-and-modders/isp_flashing_guide