There are a lot of things I don't miss! x86 segmented architecture, for example. Even modern embedded programming on an ARM Cortex-M feels luxurious compared to not that long ago.
Yep, which is somehow funny to see people discussing what you can or cannot do on ESP286 and ESP32, when compared with CP/M and MS-DOS early hardware, they are server class.
If you enjoyed this article, you might also enjoy The Man Who Mistook His Wife for a Hat and Other Clinical Tales by Oliver Sacks. It’s a book of essays about brain function and disorders, but each begins with an individual who exhibits particularly unusual symptoms. They don’t have tidy resolutions like this article, but the book is well-written and engaging—-as are the rest of Dr. Sack’s writings.
Just started reading this. It's really sucked me in, but it also fills me with a sort of biological dread. Something goes wrong with your brain-meat and suddenly you find yourself teleported 40 years into the future every time you look in the mirror, or become an unstuck, powerless spirit inside your own body.
That sounds very similar to my experience with toy development. For a toy that played a bunch of pre-recorded sounds, we used a 4-bit Winbond MCU (their MCU division is now Nuvoton) that had a tiny bit of RAM and a ton of mask ROM. Firmware development was done in assembly and targeted a huge (physically large) emulator for test/debug. When we were satisfied with the firmware, we'd send it off to our CM, who would then order the parts with our FW in ROM. They'd get back bare die parts, which were wire bonded to the PCB and then epoxied over (that miserable "glop top" packaging, which is the bane of many teardowns). Development was a bit painful, but high volume production was extremely cheap.
Edit: Oops. I conflated projects. The toy project actually used a SunPlus MCU, not a Winbond MCU. It was an 8-bit RISC CPU running at 5MHz with 128 bytes RAM and 256KB mask ROM. The ROM held both the program and audio samples. I don't recall what encoding was used for the audio.
The two examples were timepiece designs and Gilette Fusion ProGlide. On top of getting yours, I'm curious if any of these cheap MCU's in the article could today have met whatever your requirements were for a 4-bitter?
It was also for a low-cost audio application, but it wasn't a toy. This was back in 2001 or so. The MCUs in this article all only have ~1KB ROM, which wouldn't have been enough for our audio samples. We needed >256KB. The "4-bitness" was just incidentally what Winbond offered with a large ROM at the time. However, the SunPlus that we later used in the toy also offered a large ROM with an 8-bit CPU for a similar cost. So, while I can't authoritatively say that 4-bit is dead, it does seem like there are a lot of alternatives in similar price ranges now.
This is easily my favorite food video online. Possibly my favorite video online period. This technique creates a world of possibility since it creates a smooth spreadable raw allium. I recommend it to every novice and intermediate cook I know.
This is a friend’s project. It’s a public domain, header-only vsnprintf that supports floats. It has zero dependencies, zero libc calls, no allocations, < 100B stack, < 5K on a Cortex-M with optimizations on. It’s meant for small systems where you need a full-featured printf without a huge footprint.
The tl;dr is that researchers found 3 weaknesses in an STM32's flash protection scheme. For those not familiar, these chips offer three protection levels:
RDP 0 - unlocked, all flash/ram is accessible via the debug interface
RDP 1 - flash locked, you can connect a debugger and read out RAM/peripherals, but not flash. This is intended to prevent you from dumping the flash firmware image, but allow you to perform some diagnostics via the debugger.
RDP 2 - everything's locked down. The debugger cannot access RAM, Flash, or other peripherals.
The 3 exploits are roughly:
* In RDP 1, you can't read flash directly, but you can read anything that the firmware puts in RAM. The researchers were able to extract an entire flash firmware image by watching the results of a CRC self-check that the firmware performs upon boot. By resetting the microcontroller and very precisely controlling the amount of time it's allowed to run before halting it and dumping RAM, the researchers were able to back out the firmware image by observing the CRC progression in RAM.
* The researchers noted that the bit patterns used to represent the different RDP levels in flash were sub-optimal in that only a single bit needs to be flipped to downgrade from RDP 2 to RDP 1. By deencapsulating an RDP 2 microcontroller and exposing it to UV using a carefully-constructed mask, they were able to perform such a downgrade.
* The researchers crafted their own SWD debugger interface that performed less initialization than ST's stock debugger and thus didn't immediately lock down a microcontroller in RDP 1 mode when the debugger was attached. With this modified debugger, they discovered that they could issue a flash read that would lock down the micro as expected, but would also occasionally result in the protected flash data actually appearing in the read buffer (likely due to some internal race condition bug in the microcontroller's hardware). Thus it's possible to automate a brute force extraction of the entire flash in RDP 1 mode.
Edit: Changed RDP 2 to RDP 1 in description of 3rd exploit.
1. RDP2 completely disables the debug interface. The microcontroller doesn't respond to debug requests in this mode.
2. As the third attack requires the microcontroller to have a working debug port, it requires it to be in RDP1. (Which could be accomplished using the second attack.)
Ah, you're correct. I did think it was odd that they were able to make the debugger do anything in RDP2, but I misread it. That attack was indeed performed in RDP1.
A related attack (not documented here IIRC) is that if the bootloader supports encrypted firmware updates, depending on the implementation it's sometimes possible to dump the key from RAM and decrypt the firmware update itself.
Learn from that then, for the future, do what you won't regret in the future.
But be aware, it can cause its own issues. Example, dating and saying what you really feel when you do. It can cause things to end quickly, but at the very least you won't regret not having said what you felt. :)
Regrets are chains you put on your own legs that weigh you down for the rest of your lifes journey. Just put them aside and agree not to wear them again in the future.
Hi HN! You found my site again. Here's the previous discussion from almost exactly year ago (warning, this links to the profane version): https://news.ycombinator.com/item?id=13437182
