A bootloader is typically used to update application code on a microcontroller. It receives the new program from a host, writes it to flash, verifies the program is valid, and resets the microcontroller. Perhaps the most ubiquitous example is the Arduino bootloader which allows you to load code without an AVR programmer.
The bootloader resides in a special part of memory, which is protected. On the AVR, it isn’t possible to write to the bootloader memory from the application code. This is to prevent you from accidentally breaking the bootloader and bricking the device.
However, it can be useful to write to the bootloader memory. The best example would be when you need to update the bootloader itself. To accomplish this, [Julz] found a workaround that defeats the AVR bootloader protection.
The challenge was to find a way to execute the Store Program Memory (spm) instruction, which can only be executed by the bootloader. [Julz] managed to make use of the spm instruction in the existing bootloader by counting cycles and modifying registers at the right time.
Using this technique, which [Julz] calls BootJacker, the Fignition 8 bit computer could have its bootloader updated. However, this technique would likely allow you to modify most bootloaders on AVR devices.
When a Lexmark inkjet printer stopped working, [Mojobobo] was able to claim it as his own. He quickly realized that the machine was flooded with ink and not worth repairing, but that didn’t mean he couldn’t still find a use for it. When he learned that the printer’s firmware was not only upgradable but also unprotected, he knew he should be able to get the printer to do his own bidding.
[Mojobobo] started his journey with the motherboard. The unit still powered up, but it was asking to insert a “duplex module” before it would boot any further. [Mojobobo] first tried to find a way to trick the duplex module sensor, but was unsuccessful. His next step was to search for some kind of serial communications port. He didn’t have an oscilloscope, so instead he used a speaker with a wire probe. In theory, if the wire was pressed against an active serial port, he would be able to hear varying tones through the speaker. Sure enough, he found some interesting tones after probing around some ports next to a “JTAG” label. He looked up some information about the nearby chip and found that it included an SPI bus.
After some internet research, [Mojobobo] learned enough about SPI to have a rough idea of how to use it. Having limited tools available to him, he decided to use his Arduino to try to communicate with the motherboard. After wiring up a simple circuit, (and then re-wiring it) he was able to dump the first 4096 bytes of the motherboard’s boot loader to the Arduino via the SPI interface.
[Mojobobo’s] next steps will be to find a faster way to dump the boot loader. At 9600 baud, he grew tired of waiting after three hours. Once he has the full boot loader he intends to search for a way to bypass the duplex sensor and get the board to finish booting. Then he may just use the printer for its scanning functions, or he might find other interesting uses for it.
[Necromant] wrote a library to flash his microcontroller over an RF link using an NRF24L01 wireless communication module. The NRF24L01 is a cheap RF module that can be easily integrated into many microcontroller projects. Though there are Arduino libraries for driving the NRF24L01, [Necromat] decided to make a port of one with no Arduino dependencies.
The resulting bootloader fits into 4K of
RAM flash with packet loss and recovery along with user-configurable hardware or software SPI. Programming speeds are not the highest, but [ NecromatNecromant] believes this to be a property of the VUSB rather than the transfer rate from the NRF24L01 or the target microcontroller.
To program the target AVR chip, [
NecromatNecromant] used another NRF24L01 module connected to his uISP dongle over USB. Using a custom tool to interface with the uISP, the target board can be programmed in a similar fashion as avrdude. Check out the code for the ISP dongle and the AVR bootloader on his GitHub page.
Adafruit’s Trinket and digiStump’s Digispark board are rather close cousins. Both use an ATtiny85 microcontroller, both have USB functionality, and both play nice with the Arduino IDE. [Ray] is a fan of both boards, but he likes the Trinket hardware a bit better. He also prefers the Digispark libraries and ecosystem. As such, he did the only logical thing: he turned his Trinket into a Digispark. Step 1 was to get rid of that pesky reset button. Trinket uses Pin 1/PB5 for reset, while Digispark retains it as an I/O pin. [Ray] removed and gutted the reset button, but elected to leave its metal shell on the board.
The next step was where things can get a bit dicey: flashing the Trinket with the Digispark firmware and fuses. [Ray] is quick to note that once flashed to Digispark firmware, the Trinket can’t restore itself back to stock. A high voltage programmer (aka device programmer) will be needed. The flashing process itself is quite a bit easier than a standard Trinket firmware flash. [Ray] uses the firmware upload tool from the Micronucleus project. Micronucleus has a 60 second polling period, which any Trinket veteran will tell you is a wonderful thing. No more pressing the button and hoping you start the download before everything times out! Once the Trinket is running Digispark firmware, it’s now open to a whole new set of libraries and software.
Umm yeah… this is more like it. The STM32F4Stamp is a project which [Frank Zhao] put together to make his ARM prototyping process more like is was back when everything came in a DIP format. As you can see, it’s just narrow enough to leave one row open on the breadboard for jumper wires.
Don’t get us wrong, we do really like STM’s own Discovery Boards for the hardware they deliver at a very low price. But the dual-row pin headers on the larger versions (all except the F0 variant) make it tricky to connect your peripherals. This is pushed to the point that a large percentage of hacks we’ve seen with the Discovery boards are actually just to make connecting external hardware easier.
You may be thinking that there’s a lot missing from this board, but we disagree. Obviously there’s still a USB port which can be used to power the board via a 3.3V regulator. But since the STM32 chips have a built-in bootloader the USB connection can also be used to flash firmware to the processor. Nice! It’s open hardware if you want roll your own. For your convenience we’ve embedded the schematic after the break, along with [Frank’s] demo video.
Continue reading “Breadboard Friendly ARM Board Based on STM32F4”
[Andrzej Surowiec] liked the functionality of the mass storage bootloader available on some NXP LPC development boards. His latest project was to write a mass storage bootloader for the Stellaris Launchpad. It allows you to flash your compiled firmware to the chip simply by mounting the board as a USB storage device and copying over the binary file. The chip has plenty of flash memory (the bootloader itself takes up 16 KB of the available 256 KB), and the board is already set up for use as USB hardware.
There is a precompiled binary available at the linked page above or you can get the source code from his github repository. We think this project is a good stepping off point for others. For instance, it should be relatively easy to use [Andzej’s] work as the base for implementing filesystem-based I/O control like we saw in the phatIO project.
On the continuing list of homebrew ARM dev boards we’ve seen over the past few months, [Squonk42]’s USBug is one of the best we’ve seen. Like many other ARM boards, it breaks out a member of the Cortex M0/M3 family into a 40-pin DIP, but unlike all the others, [Squonk] designed it so you can drag and drop code onto the microcontroller just like a USB thumb drive.
[Squonk]’s trick relies on a certain breed of NXP LPC11xx/LPC13xx microcontrollers. These chips feature a ROM-based mass storage, meaning you can compile code on your desktop and simply shuffle it over to the USBug, no external programmer required. Here’s the relevant app note (PDF in a zip file. Double whammy).
Of course, the USBug features the I/O you’d generally expect from the current crop of Cortex-M3 devices, all while serving up 64 kB of Flash and 12 kB of RAM.
[Squonk] says he’d like to put the USBug on Kickstarter, but unfortunately he’s not a US citizen. In the spirit of Open Hardware, perhaps some maker-based electronics manufacturer will pick up where [Squonk] is forced to leave off.