Bare-Metal STM32: Exploring Memory-Mapped I/O And Linker Scripts

In the first installment of this series we had a brief look at the steps needed to get a bare-metal application running on an STM32 microcontroller. While this allowed us to quickly get to the juicy stuff, there are two essential elements which make an MCU so easy to use. One is found on the hardware side, in the form of so-called memory-mapped I/O (input/output), the other is the information contained in the files that are passed to the linker when we build a firmware image.

Memory-mapping of hardware peripheral registers is a straightforward way to make them accessible to the processor core, as each register is accessible as a memory address. This is both convenient when writing the firmware code, as well as for testing, as we can use a memory mapping specific for unit or integration testing.

We will take an in-depth look at this way of testing, as well as how these linker script files are connected to the memory layout. Continue reading “Bare-Metal STM32: Exploring Memory-Mapped I/O And Linker Scripts”

Bare-Metal STM32: Blinky And The Secret Of Delay Functions

One of the very first examples for an MCU or SoC usually involves the famous ‘Blinky‘ example, where an LED is pulsed on and off with a fixed delay. This is actually a lot more complicated than the ‘Pushy‘ example which we looked at in the first installment of this series. The reason for this is that there’s actually quite a story behind a simple call to delay() or its equivalent.

The reason for this is that there are many ways to implement a delay function on a microcontroller (MCU), each of which comes with their own advantages and disadvantages. On an STM32 MCU, we get to choose between essentially an active delay (while loop), one implemented using the SysTick timer and using one of the peripheral timers. In the latter two cases we also have to use interrupts.

In this article we’ll take a look at all three approaches, along with their advantages and disadvantages.

Continue reading “Bare-Metal STM32: Blinky And The Secret Of Delay Functions”

PET 2001 Emulator On $2 Of Hardware

Since the late 60s, Moore’s law has predicted with precision that the number of semiconductors that will fit on a chip about doubles every two years. While this means more and more powerful computers, every year, it also means that old computers can be built on smaller and cheaper hardware. This project from [Bjoern] shows just how small, too, as he squeezes a PET 2001 onto the STM32 Blue Pill.

While the PET 2001 was an interesting computer built by Commodore this project wasn’t meant to be a faithful recreation, but rather to test the video output of the Blue Pill, with the PET emulation a secondary goal. It outputs a composite video signal which takes up a good bit of processing power, but the PET emulation still works, although it is slightly slow and isn’t optimized perfectly. [Bjoern] also wired up a working keyboard matrix as well although missed a few wire placements and made up for it in the software.

With his own home-brew software running on the $2 board, he has something interesting to display over his composite video output. While we can’t say we’d emulate an entire PC just to get experience with composite video, we’re happy to see someone did. If you’d like to see a more faithful recreation of this quirky piece of computing history, we’ve got that covered as well.

Continue reading “PET 2001 Emulator On $2 Of Hardware”

Remoticon Video: How To Use Machine Learning With Microcontrollers

Going from a microcontroller blinking an LED, to one that blinks the LED using voice commands based on a data set that you trained on a neural net work is a “now draw the rest of the owl” problem. Lucky for us, Shawn Hymel walks us through the entire process during his Tiny ML workshop from the 2020 Hackaday Remoticon. The video has just now been published and can be viewed below.

This is truly an end-to-end Hello World for getting machine learning up and running on a microcontroller. Shawn covers the process of collecting and preparing the audio samples, training the data set, and getting it all onto the microcontroller. At the end of two hours, he’s able to show the STM32 recognizing and responding to two different spoken words. Along the way he pauses to discuss the context of what’s happening in every step, which will help you go back and expand in those areas later to suit your own project needs.

Continue reading “Remoticon Video: How To Use Machine Learning With Microcontrollers”

A Straightforward Guide To Unlocking The Nintendo Game And Watch

Nintendo’s reborn tiny handheld game has certainly attracted the attention of hardware hackers, and we’ve been treated to a succession of exploits as its secrets have been one by one unlocked. With relatively straightforward hardware it conceals potential far beyond a simple Mario game or two, and it’s now at the stage of having a path to dumping both its SPI Flash and internal Flash, unlocking its processor, and running arbitrary code. The process of unlocking it is now atraightforward enough to warrant a HOWTO video, to which [stacksmashing] has treated us. It’s early days and this is still touted as for developers rather than gamers, but it serves to show where work on this console is going.

The console’s STM32 architecture means that programming hardware is straightforward enough to find, though we’re cautioned against using the cheap AliExpress type we might use with a Blue Pill or similar. Instead the snap-off programmer that comes with an STM Nucleo board is a safer choice that many people are likely to have already.

The relative simplicity of the process as seen in the video below must conceal an immense amount of work from multiple people. It’s a succession of scripts to sequentially unlock and back up the various firmwares with STM payloads for each step. Finally the STM32 itself is unlocked, and the backed-up Nintendo firmware can be returned to the device or instead a custom firmware can be created. Aside from the DOOM we’ve already seen there are work-in-progress NES and Game Boy emulators, and fascinatingly also work on bare-metal games.

Given the lack of custom chips in this console it is easily possible that its hardware could be directly cloned and that Nintendo might have unintentionally created a new general purpose hacker’s handheld gaming platform. There are a few hardware works-in-progress such as increasing the SPI Flash size and finding the unconnected USB pins, so we look forward to more exciting news from this quarter.

Continue reading “A Straightforward Guide To Unlocking The Nintendo Game And Watch”

DOOM Running On The Nintendo Game & Watch

Today the newly-released Nintendo Game & Watch can play DOOM. Sure, there are caveats…this is a watered down version due to the restraints of the hardware itself. But the important thing is that this shows the hardware has been fully owned. This is code written to replace the firmware that ships on the STM32 within, and that makes this a gorgeous little hardware platform that is completely open to homebrew hacking.

Honestly, you had to assume this was going to happen pretty quickly considering the effort being thrown into it. We first reported on Tuesday that the EEPROM memory which stores the ROMs on the Game and Watch had been decoded. Shortly after that was published, [stacksmashing] and [Konrad Beckmann] were showing test patterns on the display and mentioning the audio was working as well. Turns out they were able to dump the stock firmware despite the chip being security locked.

We’ll have to wait for more details on exactly how to dump firmware, but [stacksmashing] drops enough of a mention in the video below to confirm the obvious. A common approach to dumping code from a locked microcontroller is to find a vulnerability that grants execution of custom code. Being able to run just a few lines of your own code is enough set up something as simple as looping through all internal flash memory addresses and dumping them over a few GPIO pins. In this case our two heroes discovered some ARM code was being loaded from the EEPROM onto the STM32, and managed to inject their own directives to perform the dump. They have promised full details soon.

What we have today is a pretty tricky hack not just to load code, but to get DOOM to run on meager hardware specs. Notably, 128 k of SRAM and 1.3 MB of external RAM. There’s also a bottleneck with the 1.1 MB of FLASH for storing game files. The textures were stripped down, and memory allocation was rewritten, but the proof of concept is there and the game runs. Homebrew, here we come!

Continue reading “DOOM Running On The Nintendo Game & Watch”

Blue Pill As A Nerdy Swiss Army Knife

Not everyone can afford an oscilloscope, and some of us can’t find a USB logic analyzer half the time. But we can usually get our hands on a microcontroller kit, which can be turned into a makeshift instrument if given the appropriate code. A perfect example is buck50 developed by [Mark Rubin], an open source firmware to turn a STM32 “Blue Pill” into a multi-purpose test and measurement instrument.

buck50 comes with a plethora of functionality built in which includes an oscilloscope, logic analyzer, and bus monitor. The device is a two way street and also comes with GPIO control as well as PWM output. There’s really a remarkable amount of functionality crammed into the project. [Mark] provides a Python application that exposes a text based UI for configuring and using the device though commands and lots of commands which makes this really nerdy. There are a number of options to visualize the data captured which includes gnuplot, gtk wave and PulseView to name a few.

[Mark] does a fantastic job not only with the firmware but also with the documentation, and we really think this makes the project stand out. Commands are well documented and everything is available on [GitHub] for your hacking pleasure. And if you are about to order a Blue Pill online, you might want to check out the nitty-gritty of the clones that are floating around.

Thanks [JohnU] for the tip!