search

qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.24k stars 39.3k forks source link

New Firmware Caused Memory to Overflow[Bug] #11775

Closed Aidan-OS closed 3 weeks ago

Aidan-OS commented 3 years ago

Describe the Bug

I received my DZ60 a couple of weeks ago and initially used VIA to program it. After about a week, the board stopped lighting up and typing when plugged into my Macbook, and VIA would no longer detect it. I went to test with a PC and had the same results. I then used the QMK Configurator website to create a .hex file and was able to flash this to my board, making it work again.

Fast forward another week and the keyboard again stopped working. This time the lighting still worked but nothing would happen when I typed on it. Oddly enough, the keyboard still worked when I went to try it with a windows PC, and that led me to start looking around. I believe this issue to be the same as this, but even worse.

I went to go and use an older version of qmk (0.10.51) to create my .hex file and ran into an even bigger issue: image

From looking around for this issue, I have determined that I need to ISP flash the board or replace it altogether. Are there any other options I may have? Am I incorrect in identifying what went wrong here?

System Information

Additional Context

Aidan-OS commented 3 years ago

ISP flashing and using an older version of QMK has gotten the board back to a working state. Will keep updated ;on if it breaks again.

dongocduy commented 3 years ago

U can disable some macro define not necessary in rules.mk ex: MOUSEKEY_ENABLE = no

Aidan-OS commented 3 years ago

It has been done, I will let you know if anything happens as a result.

Aidan-OS commented 3 years ago

Annnnd it died again. It seems to be something to do with the computer going to sleep or waking up from sleep, I am not entirely sure which. Good news is that it didn't die too hard so I didn't need to ISP flash again.

Aidan-OS commented 3 years ago

This issue continues to recur, even on the most recent versions of QMK. If the computer happens to die when the keyboard is plugged in, it forces me to ISP flash.

I really need this fixed. The person who uses this keyboard isn't very tech savvy and they are leaving an area in which I can help them come September.

drashna commented 3 years ago

This issue continues to recur, even on the most recent versions of QMK. If the computer happens to die when the keyboard is plugged in, it forces me to ISP flash.

To be blunt, no matter what bootloader you're using, or even what chip you're using, if that happens, then yeah, it will brick it.

Annnnd it died again. It seems to be something to do with the computer going to sleep or waking up from sleep, I am not entirely sure which. Good news is that it didn't die too hard so I didn't need to ISP flash again.

You could add #define NO_USB_STARTUP_CHECK This will disable usb suspending firmware side, and may help with the issue.

tzarc commented 3 years ago

Honestly sounds like something electrical is at play, here. No functionality in QMK is present for AVR devices to write to flash memory, so if reflashing is required, something else is affecting matters -- perhaps EEPROM. Also of note, DZ60 seems to have no ESD protection, so if you've got the board in an environment that generates a lot of static electricity, something might be zapping it.

Swapping different versions of QMK will likely force EEPROM reset, due to differing IDs -- if you hold <Space>+<Backspace> while plugging the board in, does it come good?

Aidan-OS commented 3 years ago

To be blunt, no matter what bootloader you're using, or even what chip you're using, if that happens, then yeah, it will brick it.

You are kidding right? Then why doesn't my mouse brick when my computer crashes? Why doesn't anything but my keyboard start failing? This is clearly a problem with QMK.

You could add #define NO_USB_STARTUP_CHECK This will disable usb suspending firmware side, and may help with the issue.

This is worth checking. I will test this.

Also of note, DZ60 seems to have no ESD protection, so if you've got the board in an environment that generates a lot of static electricity, something might be zapping it.

I doubt this is the issue, as there should be pretty much no chance of it ever getting shocked. The keyboard I have used on my windows machine only that also has a DZ60 PCB has never had an issue, so I am strongly lead to believe that this is a problem with QMK and MacOS.

if you hold <Space>+<Backspace> while plugging the board in, does it come good?

I will have to try this the next time anything bad happens.

sigprof commented 3 years ago

Note that DZ60 and DZ60RGB are significantly different boards, and your flashing log shows the dztech/dz60rgb_ansi/v2 model; you should not call this PCB “DZ60” (yes, the KBDfans board naming is confusing).

The <Space>+<Backspace> suggestion, which would be valid for DZ60, is not suitable for DZ60RGB (the <Space>+<Backspace> combination is used by the older “full Bootmagic” feature that is traditionally enabled in DZ60 non-VIA firmwares, but the firmware for DZ60RGB uses Bootmagic Lite). For your DZ60RGB board the way to reset EEPROM is to hold <Esc> while plugging the board in, but this also makes it enter the bootloader; if you don't want to reflash the firmware at that time, you can just unplug and replug the board normally after doing that. If you are using the VIA firmware, resetting the EEPROM this way will also reset the VIA keymap to default.

And the increasing amount of similar issues from people having DZ60RGB or DZ65RGB boards makes it look like the more recent batches of these PCBs have some dodgy hardware (maybe someone decided to use the ongoing chip shortage as a chance to sell some sub-par batch of MCUs that they had). E.g., the inability to reflash the firmware looks like some protection fuses have been toggled, which cannot happen in normal usage.

samuelmtthw commented 3 years ago

I'm also having the same problem with my KBD67 mkii RGB-V2 from the kbd67 lite. Looks like this problem belongs to QMK & MacOS.

Seems like ISP Flashing is the only solution that I can do for now, or do we have updates for this problem? Re-flashing your bootloader everytime is more painful than re-flashing the firmware itself (although it's still painful)

tzarc commented 3 years ago

Again, there is no code inside QMK that is capable of entering any mode to perform in-application programming.

QMK quite literally does not have the capability to rewrite portions of flash memory or the fuses.

If you need to reflash bootloader to recover it, something else is at play.

Andrew-Fahmy commented 2 years ago

I am having a similar problem with my K type. I flashed it a day or two ago and this morning the lighting has stopped working. I am on linux so it may not be unique to MacOS.

Swapping different versions of QMK will likely force EEPROM reset, due to differing IDs

This is what I have to do for the lighting to work when flashing my keyboard. Is it possible that the firmware is larger now and overwriting data it shouldn't?