Is it possible to (non-permanently) write protect an ATMega32U4?

[Nazo]

I have an Idobo75 clone based on the ATMega32U4. I'm still not sure exactly what happened, but during an improper shutdown (my fault I 100% admit!) it stopped working with my computers, yet, interestingly enough still functioned enough to do things like switch layers (I have it programmed to change the backlight depending on the layer) which clued me in to the fact it wasn't truly dead. I tried reflashing it and lo and behold, it works 100% normally again now. My best conclusion is somewhere along the way of the improper shutdown some bit of the firmware was damaged. Since it stays writable so you can do things like change layouts in programs such as VIA this does at least seem theoretically possible.

What I'd like to know and at least try and see what happens in this regard is to see if there is a way I can sort of write protect the firmware. In my attempts to google I've found some vague mention of fuses, but that obviously would be a mostly permanent solution (depending on implementation, I'm not sure. Perhaps 100% permanent.) This is a bit extreme and would probably be more trouble than it's worth in case I ever need to change anything else (possible, though things are mostly finalized at this point so I honestly don't know for sure.) I'd definitely rather not do this, but anyway, it may require an external programmer and I'm not really setup for that. I'm wondering if there is something simple I can do with, say, avrdude or whatever just to temporarily mark it as write protected that can be disabled via the same method.

Is this even possible?

 

[michalrz]

I'm a noob and I don't know much, but if the device doesn't need the reset pin for normal operation, you could physically cut the reset pin's connection and/or pull it to Vcc with a resistor. Can't program things without the reset pin.
But, I think this is more of a corruption issue and you can't really tell the device to stop forgetting stuff.

 

[grim4593]

The ATMega32U4 can be set up with two memory segments; one for the bootloader and one for the application code. The write protection can be applied to either of the memory segments independently. According to the datasheet errant memory corruption can occur if the MCU is at brownout voltages if brownout protection is disabled and the memory section isn't locked. It is likely that your chip is set up with a write protected bootloader only which is why only the application memory was corrupted and you were able to reflash it.

I am more familiar with Microchip PIC MCU programming, but I think you need to open up the code and recompile it with the appropriate fuse bits set either in code or through the IDE. Page 358 of the linked datasheet shows the registers to use. However, if this is done through the Arduino IDE I am sure there is a more simple IDE driven method to enable this locking.
I've read that if you lock the application memory the bootloader can still reprogram it as long as it runs the erase command on that memory segment. Might need a little more research.

 

[Nazo]

I'm a noob and I don't know much, but if the device doesn't need the reset pin for normal operation, you could physically cut the reset pin's connection and/or pull it to Vcc with a resistor. Can't program things without the reset pin.

I would definitely have no idea how I would go about doing that.

It is likely that your chip is set up with a write protected bootloader only which is why only the application memory was corrupted and you were able to reflash it.

Well, I've been using VIA and QMK. I don't know the precise details, but they do establish a more "open" bootloader that has a few bonuses versus what such devices tend to ship with like being able to enter flash mode by holding button one when powering the device on. I don't need that particular feature (I drilled a hole directly over the physical button so I can enter reflash mode with the help of a pen or whatever,) but I also don't have any other bootloader available personally that I could just write to it and wouldn't really know what to look for in regards to something that would actually still work with the semi-custom QMK firmware I've built. (The only thing I truly customized in it was adding the light changing per layer code that I copied and pasted from elsewhere -- the rest is autogenerated from their website's tool.)

I am more familiar with Microchip PIC MCU programming, but I think you need to open up the code and recompile it with the appropriate fuse bits set either in code or through the IDE. Page 358 of the linked datasheet shows the registers to use. However, if this is done through the Arduino IDE I am sure there is a more simple IDE driven method to enable this locking.
I've read that if you lock the application memory the bootloader can still reprogram it as long as it runs the erase command on that memory segment. Might need a little more research.

This sounds like the kind of thing I would be looking for, but I would definitely have no clue how I could possibly go about it. I wouldn't even know what to look for. All I can really say is that I am using the standard tools that QMK provided in the past (I haven't updated in a little while, so it may be outdated, but I think not by much.) It has a sort of compiler that you run to build the custom layout files into something that the toolbox can flash. I'm guessing from what you say it would be the custom layout file that you feed the builder that would need to be modified, which is reasonably easy to do on its own, but I wouldn't even have the slightest idea what to put in there to achieve this. Either way, even looking at that document I don't really know what I would do. I probably should have added to the first post I'm a noob when it comes to actually programming these things. QMK and VIA do all the actual work for me and I know very little of what is going on in the background. I was hoping there might be some simple command I could feed to avrdude or whatever to achieve this (or I guess code I could add to the QMK custom layout that gets compiled.)

Actually, I can add something that may or may not help clarify which maybe might help confirm what you're talking about. I use a KVM to switch between two computers and sometimes if I switch the KVM from the second computer to the first while the first is turned off, the keyboard seems to sort of get stuck and I have to unplug it and replug it, but then it works fine. I wonder if this may be related (could be a brownout style issue since the KVM no longer has it directly connected to anything and it should be receiving power more passively, so perhaps isn't fully powering devices.) Not sure if that's related or not, but it sounds like it could be. (Also it would be nice if I could fix that anyway.) Another thing of interest along these lines is that I have a KBDFans KBDPad MKII, which uses a similar chip, the ATMega32U2. It has never freaked out with the KVM thing and when this keyboard corrupted on that power loss it still remained completely fine and normal.

It sounds like you're on to something though. I worry about it if it actually burns fuses or something as I might someday down the road need to change something, but if it's possible to override that when switching to proper flash mode via the switch on the bottom that's all I really need.

 

[grim4593]

They aren't actually fuses in the electrical sense - they are more like circuit breakers that can only be turned back on during reprogramming. Link
I just looked up QMK and VIA - It might not be impossible to do what you are asking but in the best case it sounds like it could be a very deep rabbit hole. And the act of write protecting the firmware might be against the functionality of the service.
This link MIGHT be able to get you started down the right path. It tells you how to set up a QMK build environment and the link at the bottom walks you through the firmware compilation process.
The table of contents on the left also has a link to a discord server for support.

 

[Nazo]

They aren't actually fuses in the electrical sense - they are more like circuit breakers that can only be turned back on during reprogramming.

Oh, ok. That is an important point of clarity since burning fuses to make effectively permanent changes is an actual thing in some electronics.

I just looked up QMK and VIA - It might not be impossible to do what you are asking but in the best case it sounds like it could be a very deep rabbit hole. And the act of write protecting the firmware might be against the functionality of the service.
This link MIGHT be able to get you started down the right path. It tells you how to set up a QMK build environment and the link at the bottom walks you through the firmware compilation process.
The table of contents on the left also has a link to a discord server for support.

Ok. It's probably beyond me to do any of the extras (I do have the QMK build environment already setup, but I don't know about making major firmware changes like fuse switching,) but I may try asking on the Discord perhaps (I really get tired of joining half a million discord servers all of which want to ping me all the time and I have to manually mute then eventually leave again when done and rejoin as needed, etc etc.) Either way, thanks for the info up to this point. At the very least I know it maybe isn't necessarily 100% impossible.