Qmk_firmware: RESET/DFU not working on TADA68

[AndreasBackx]

I was working on my own layout for my TADA68 and while doing so I found that the RESET keycode doesn't seem to trigger the keyboard to go into DFU mode and dfu-programmer also doesn't detect the keyboard while it's in its reprogrammable state. Is there a way I can perhaps make a PR to get this to work? Where would I start?

[fredizzimo]

According to the instructions, the TADA68 has a special way of flashing it, so it probably don't work at all with the dfu-programmer.

That custom bootloader is also probably the reason why the reset button doesn't do anything.

[evyd13]

What if one would flash a different bootloader to the chip?

[evyd13]

Maybe this will help.
http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__software_bootloader_start.html

The file where this probably should be implemented is tmk_core/common/avr/bootloader.c.

[evyd13]

I'm a bit blind; a link to that is in the file itself. Tried a lot of stuff to get it working but I didn't succeed.

[fredizzimo]

I'm just guessing, but based on the way that this keyboard is flashed, it's using the lufa mass storage bootloader. The instructions for that, states that the bootloader size is 6KB plus an auxillary section.

So based on that, I think the jump should work if you change the bootloader size to 6KB in the makefile.

[skullydazed]

I'm closing this to clean up our open issues, but if you still have questions @AndreasBackx and @Maartenwut please reopen this or open a new issue.

[tokyovigilante]

Hi, sorry to resurrect an old bug, but is there any clarification on whether software DFU is possible on this board, by changing the bootloader memory size or otherwise? I know it's a bit of an odd-ball flashing mechanism, but the board is otherwise great with QMK, it's just a pain to have to keep disassembling it every time I want to update the keymap. Thanks!

[fauxpark]

The Tada68 doesn't have DFU, when in bootloader mode it appears as a mass storage device, and is very susceptible to bricking. Could you try adding BOOTLOADER_SIZE = 6144 to the rules.mk and see if that works?

[tokyovigilante]

Will give it a roll, thanks for the reply. The 6K/ 6144 byte figure that was mentioned before however, I've read the LUFA docs above and it comments:

...with an 8KB bootloader section size, and will fit into 6KB of bootloader space...

Does 6K definitely apply here?

[fauxpark]

That sentence relates to the AT90USB128 which the LUFA mass storage bootloader builds for by default, but the Tada68 is using an ATmega32U4. The max bootloader section size for the former is 8kB, and 4kB for the 32U4. Thus you lose 2kB of firmware space when using this bootloader on anything with less than 128kB of flash (basically only the USB128) as the FAT filesystem code is just too large to fit in 4kB.

[tokyovigilante]

Make sense, thanks for clarifying. Will try later in the day and report.

[tokyovigilante]

Unfortunately this doesn't seem to help. Rebuilding with make tada68:<keymap>:flashbin results in a file with an updated shasum so I assume the updated bootloader size to 6144 (in bootloader.mk) seems to have taken in the build, but the behaviour is the same. The keyboard LEDs flash off and on once, so I assume the board has reset, but does not enter the mass storage flashing mode.

[fauxpark]

So the keyboard level rules.mk has the Command feature enabled, which will change the checksum on every build because it bakes in the build time along with some other diagnostic info eg. compiler version. If I disable that and add BOOTLOADER_SIZE = 6144 directly underneath the BOOTLOADER rule, I get the same MD5 as without Command or BOOTLOADER_SIZE. Commenting out BOOTLOADER results in a different MD5.

[drashna]

Another option is to simply replace the bootloader with something less ... fragile. You can use an ISP flasher to replace the bootloader and change the fuses to use DFU instead. This may be a better long term solution, too.

[tokyovigilante]

Thanks @fauxpark I'd run several builds without the checksum updating, but will give it another crack this evening. The only other thing I noticed is that the boot key differs from the published boot key in the LUFA documentation, but even swapping the key didn't help.

@drashna good to know that's an option, when you say "change the fuses" is that a HW mod? I'm not the world's most competent solderer (although did get all the switches in without needing to visit a burns unit...) Is there any documentation for that process (the actual flashing with an ISP programmer looks relatively straightfoward), and reliable source for the firmware or build instructions? Thanks.

[fauxpark]

Fuses in the context of AVRs are not the electrical component, they're more like EEPROM memory and are used to configure some low level stuff about the chip: https://hackaday.com/2012/08/30/avr-fuse-bits-explained/
You'll be able to modify them using avrdude when ISP flashing. Drashna has a great Reddit post about ISP flashing the QMK-DFU bootloader (the target is a Pro Micro but it can work for this board too): https://www.reddit.com/r/olkb/comments/8sxgzb/replace_pro_micro_bootloader_with_qmk_dfu/

[tokyovigilante]

Oh right, makes much more sense. That's great thanks, I might get a hold of a programmer and give it a crack.

[tokyovigilante]

So after a stressful evening with a USBasp, avrdude and crossed fingers I've got the QMK bootloader installed on my board, and it's great! Quick key combo into DFU mode, with LED feedback and escape to exit, and command-line flashing with the QMK build tools works great. This is exactly what I wanted out of the board, thanks @fauxpark and @drashna for your help!