Braids firmware wave can brick module


In the process of writing the next release of Braids Renaissance (details at I have found that I can brick my retail Braids module via wave upload. I think the issue is that the firmware is slightly too large. When the firmware is quite a bit too large, the compilation fails with the expected error about the contents not fitting in flash.

The consequence is that, after wave upload the unit fails to restart, and then on power cycle the display remains blank. I fixed the unit by reducing the firmware size a bit, and reflashing the module via JTAG. After that wave upload was okay until I hit the magic code size issue again.

I uploaded the code that yields this “bricking” firmware here

I also can provide the compiled braids.hex/braids.wav but for safety’s sake won’t upload them here in case someone accidentally finds it and bricks their module.

Is this a known issue? Will all Braids modules in the wild have the same maximum firmware size? My worry is that I release a firmware that uploads okay on my unit but bricks someone else’s unit due to a larger bootloader.


Yes, absolutely, which is why it is vital to check the image size before installing the firmware (or releasing it for others to install). However, all the STM32F103 chips used in Braids will have the same flash size. I forget the critical maximum size, but it is mentioned in Olivier’s notes about how to compile the firmware (and he even recommends use of cowsay to ennunciate the image size, so you don’t overlook this important point in your enthusiasm to try out your new firmware).

Note all the warnings I provide re BiiT installations:

There’s was another way to brick modules via audio uploads. Or at least to prevent downgrades. Earlier versions of the Braids firmware didn’t include code to fall back to default settings, so that if you installed new firmware that changed the settings layout in a particular way, it was impossible to re-install the factory firmware (well, you could install it, but it would immediately crash, effectively bricking the module). But that was fixed by Olivier in Braids v1.6 or 1.7 iirc, so now it is always possible to re-install factory firmware via audio.

Just btw, I took legal advice (from my sister, but she is a lawyer) about legal liability for bricked or damaged modules resulting from alt firmware distributed under my name, and she confirmed that yes, there is definitely a possibility for liability for damages claims. She recommended the addition of all the warnings I linked to above, to mitigate the risk. However, any claims would need to be brought against me here in Australia, where, under our consumer protection laws, they need to go through an arbitration process first. Provided that I offered to refresh the firmware on any bricked modules, then it would be unlikely to be allowed to go to the courts, and I would not be sued. Hence all the arrangements I made for unbricking on three continents as described in the link above. Obviously the legal situation in other countries will differ. But in general, just because your alt firmware is open-source and not sold doesn’t mean that you are not liable for any damages to modules caused by it - so plan ahead accordingly. That said, the risk is small, but no-one wants to be sued, and people can become nasty very quickly, especially if there are sizeable numbers of affected module owners all discussing the problem in some web forum.

1 Like

Tim - that’s crazy! I’d never considered liability for free open source software! I always thought the onus would be on the user! Wow!

Thanks Tim for the detailed reply!

Until it becomes prohibitively expensive I’m okay accepting the risk of having to ship some modules around to unbrick them at my cost.

Do you mind if I link to off my firmware’s page? It would be easier than me doing a poor job of replicating the information present.

The one thing I’m still not sure about is, why bother with cowsay instead of just hard failing if the firmware is too large? Am I missing something? Is there a reason someone would want a firmware that’s too big?

In short: you get a hard error message from the linker when the firmware is too large for the chip (exceeds 128k - 16k).

But you don’t get a hard error message when the firmware code overlaps with the flash area used for saving settings (128k - 16k - 4k) - because the size of the area used for settings is defined on a module per module basis, in the code itself, so the linker is not aware of it.

1 Like

Perfect. Just found the size make target and knowing that limit I can deal accordingly. Thanks!

I don’t mind, but the information regarding unbricking services is a bit out of date. Raph Wlodarczyk is still around in the US, but I don’t think Michel Morin is still active in Berlin. But that was written in 2015 - now there are a lot more people able to unblock an MI module via the FTDI serial or JTAg interfaces. Why don’t you just copy the text and update it, rather than link to it? That’s fine with me.

Well, it probably varies from country to country, but we have quite good consumer protection laws here in Oz which do not permit the vendor (and that includes open-source stuff sold fro zero dollars) to force the consumer to waive their protection rights. Thus, you can distribute open-source software or firmware with all the disclaimers and license conditions that waive the rights of the end user to claim damages, but they don’t mean a thing (at least not here in Oz) - the consumer still has the right to claim compensation if the product doesn’t work as described or causes damage in some foreseeable way.

No idea what the situation is in other countries.

All that said, I don’t think any of this is a reason not to distribute alt firmware. You just need to think it through and take reasonable precautions. The most important precautions, which I observed religiously while developing Bees-in-the-Trees and Dead Man’s Catch, was to assemble a team of willing beta testers (for BiiT I had 5 or 6, for DMC just two), all of whom have the ability to unbrick their own modules if required, and always get them to test installation and use of every new version of the firmware that is to be released, before it is released. And to test things like down-grading and re-installtion of factory firmware yourself, repeatedly. Doing that is all very tedious, but you really want to be certain that you are not releasing alt firmware that will inadvertently brick a whole lot of modules, but that’s what is needed if you are writing stuff that runs on bare metal, as the Mutable firmware does. The only exception was for minor bug fixes. For modules like Ornament and Crime, which runs on a Teensy dev board with a separate firmware boot loader and control system that can’t be overwritten by the end user (or at least, not without some effort and knowledge other part), and a USB port, then the situation is different, because the module is always recoverable with nothing more than a USB cable and a point-and-click firmware installer.

Well, for me personally I’d kept YAM for my own amusement and never released or distributed it if I’d been aware of these kinds of considerations and potential liabilities.

1 Like

I guess I come from a background of the early days of minix/bsd/linux and GNU where it was very much the user’s responsibility - if you used that software and something bad happened then it was your fault for not checking it properly and not understanding it well enough and you just got on and fixed it. I guess I viewed the alt firmwares the same way - I wouldnt install one if I didnt have the source so that I could mess with it if needed… also, I’d never install any firmware if I couldn’t unbrick one via jtag (or replace an atmega ‘cos I cant unbrick them myself!)

Food for thought thought! I have given people hacked versions of firmware without thinking about it at all…