Closed tlyu closed 2 years ago
Looking at disassembled factory bootloader code, it looks like there is no SEI
instruction in it at all, nor any SREG
writes that might enable global interrupts. So maybe it was never working to begin with! Fortunately, that also means it's not jumping into (possibly corrupted or erased) application interrupt handlers by turning on SPIE
.
That explains "how could this ever work?!": multiple errors happened to cancel out.
It's probably best to keep interrupts disabled throughout the bootloader.
That flash of color has been a longstanding mystery for us. What I'd believed was happening was that the LEDs themselves don't come up with clean state. I'm pretty sure, but not 100% positive that the flash of color happened even when the keyscanners were flashed with the raw keyscanner without the bootloader.
Since the Model 01 is no longer in production, few folks are all that likely to flash their attiny bootloaders, and the design is a little different on the Model 100, this fix may be of limited global utility. That said, if you're interested in hacking on it, I'm happy to take patches and do some local investigation as time allows.
On Fri, May 20, 2022 at 10:22 AM Taylor Yu @.***> wrote:
I was looking at the LED clearing code, and it looks like it won't work properly once the application interrupt vectors have overwritten the ones initially programmed with the bootloader. Right now when powering on my Model 01, random LEDs light up until the greeting mode turns on (the breathing "LED" key). Maybe the LED clearing in the bootloader should happen synchronously.
Right now, once the application code is flashed, the SPI interrupt goes to the application code, even while the bootloader is running. The buffers won't be initialized, and maybe worse things will happen if stuff gets rearranged in the application code. These seem like good reasons to leave the SPI interrupt off in the bootloader.
Also, it probably should be modeled after the code in the keyscanner, because it looks like the APA102 protocol requires the 1-bits in order for an LED to recognize that it's being addressed, so writing only zeroes won't accomplish turning them off.
— Reply to this email directly, view it on GitHub https://github.com/keyboardio/attiny_i2c_bootloader/issues/4, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALC2EJC4L6DH2H5XSJK3TVK7C57ANCNFSM5WQCZ7LQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I was looking at the LED clearing code, and it looks like it won't work properly once the application interrupt vectors have overwritten the ones initially programmed with the bootloader. Right now when powering on my Model 01, random LEDs light up until the greeting mode turns on (the breathing "LED" key). Maybe the LED clearing in the bootloader should happen synchronously.
Right now, once the application code is flashed, the SPI interrupt goes to the application code, even while the bootloader is running. The buffers won't be initialized, and maybe worse things will happen if stuff gets rearranged in the application code. These seem like good reasons to leave the SPI interrupt off in the bootloader.
Also, it probably should be modeled after the code in the keyscanner, because it looks like the APA102 protocol requires the 1-bits in order for an LED to recognize that it's being addressed, so writing only zeroes won't accomplish turning them off.