Doing 1080p Video, Sort Of, On The STM32 Microcontroller

When you think 1080p video, you probably don’t think STM32 microcontroller. And yet! [Gabriel Cséfalvay] has pulled off just that through the creative use of on-chip peripherals. Sort of.

The build is based around the STM32L4P5—far from the hottest chip in the world. Depending on the exact part you pick, it offers 512 KB or 1 Mbyte of flash memory, 320 KB of SRAM, and runs at 120 MHz. Not bad, but not stellar.

Still, [Gabriel] was able to push 1080p at a sort of half resolution. Basically, the chip is generating a 1080p widescreen RGB VGA signal. However, to get around the limited RAM of the chip, [Gabriel] had to implement a hack—basically, every pixel is RAM rendered as 2×2 pixels to make up the full-sized display. At this stage, true 1080p looks achievable, but it’ll be a further challenge to properly fit it into memory.

Output hardware is minimal. One pin puts out the HSYNC signal, another handles VSYNC. The same pixel data is clocked out over R, G, and B signals, making all the pixels either white or black. Clocking out the data is handled by a nifty combination of the onboard DMA functionality and the OCTOSPI hardware. This enables the chip to hit the necessary data rate to generate such a high-resolution display.

There’s more work to be done, but it’s neat to see [Gabriel] get even this far with such limited hardware. We’ve seen others theorize similar feats on chips like the RP2040 in the Pi Pico, too. Video after the break.

Continue reading “Doing 1080p Video, Sort Of, On The STM32 Microcontroller”

Switch Your RP2040 Between 3.3 V And 1.8 V

Ever want to build a RP2040 devboard that has everything you could ever want? Bad news,  “everything” also means adding 1.8 V GPIO voltage support. The good news is that this write-up by [xenia] explains the process of adding a “3.3 V/1.8 V” slide switch onto your board.

Some parts are obvious, like the need to pick a flash chip that works at either voltage, for instance. Unfortunately, most of them don’t. But there’s more you’d be surprised by, like the crystal, a block where the recommended passives are tuned for 3.3 V, and you need to re-calculate them when it comes to 1.8 V operation – not great for swapping between voltages with a flick of a switch. Then, you need to adjust the bootloader to detect the voltage supplied — that’s where the fun begins, in large part. Modifying the second stage bootloader to support the flash chip being used proved to be quite a hassle, but we’re graced with a working implementation in the end.

All the details and insights laid out meticulously and to the point, well-deserved criticism of Raspberry Pi silicon and mask ROM design choices, code fully in Rust, and a success story in the end – [xenia]’s write-up has all you could wish for.

Want to learn more about the RP2040’s bootloader specifically? Then check this out — straight out of Cornell, a bootloader that’s also a self-spreading worm. Not only is it perfect for updating your entire RP2040 flock, but it also teaches you everything you could want to know about RP2040’s self-bringup process.

This Week In Security: Password Sanity, Tank Hacking, And The Mystery 9.9

It looks like there’s finally hope for sane password policies. The US National Institue of Standards and Technology, NIST, has released a draft of SP 800-63-4, the Digital Identity Guideline.

There’s password guidance in there, like “SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords” and “SHALL NOT require users to change passwords periodically.” NIST approved passwords must be at least 8 characters long, with a weaker recommendation of at least 15 characters. Security questions like name of first pet get the axe. And it’s strongly recommended that all ASCII and Unicode characters should be acceptable for passwords.

This is definitely moving in the right direction. NIST guidelines are only binding for government services and contractors, though they do eventually get picked up by banks and other industries. So there’s hope for sane password policies eventually.

Tank Hacking

Researchers at Bitsight are interested in infrastructure security, and they opted to take a closer look at Automatic Tank Gauging (ATG) systems. Those are found at gas stations, as well as any other facility that needs automated monitoring of liquids or gasses in a tank. There is an actual ATG message format, originally designed for RS-232 serial, and woefully unprepared for the interconnected present. The protocol allows for an optional security code, but it maxes out at only six alpha-numeric characters.

Among the vulnerabilities getting announced today, we have a pair of CVSS 10 command injection flaws, a quartet of 9.8 authentication bypass flaws, with one of those being a hardcoded credential — AKA a backdoor. The other CVSS9+ flaw is a SQL injection, with a trio of slightly less serious flaws. Continue reading “This Week In Security: Password Sanity, Tank Hacking, And The Mystery 9.9”

Labelled die of the Ramtron FM24C64 FeRAM chip. (Credit: Ken Shirriff)

Inside A 1999 Ramtron Ferroelectric RAM Chip

Structure of the Ramtron FeRAM. The image is focus-stacked for clarity. (Credit: Ken Shirriff)
Structure of the Ramtron FeRAM. The image is focus-stacked for clarity. (Credit: Ken Shirriff)

Although not as prevalent as Flash memory storage, ferroelectric RAM (FeRAM) offers a range of benefits over the former, mostly in terms of endurance and durability, which makes it popular for a range of (niche) applications. Recently [Ken Shirriff] had a look inside a Ramtron FM24C64 FeRAM IC from 1999, to get an idea of how it works. The full die photo can be seen above, and it can store a total of 64 kilobit.

One way to think of FeRAM is as a very small version of magnetic core memory, with lead-zirconate-titanate (PZT) ferroelectric elements making up the individual bits. These PZT elements are used as ferroelectric capacitors, i.e. the ferroelectric material is the dielectric between the two plates, with a positive voltage storing a ‘1’, and vice-versa.

In this particular FeRAM chip, there are two capacitors per bit, which makes it easier to distinguish the polarization state and thus the stored value. Since the distinction between a 0 and a 1 is relatively minor, the sense amplifiers are required to boost the signal. After a read action, the stored value will have been destroyed, necessitating a write-after-read action to restore the value, all of which adds to the required logic to manage the FeRAM. Together with the complexity of integrating these PZT elements into the circuitry this makes these chips relatively hard to produce and scale down.

You can purchase FeRAM off-the-shelf and research is ongoing, but it looks to remain a cool niche technology barring any kind of major breakthrough. That said, the Sega Sonic the Hedgehog 3 cartridges which used an FeRAM chip for save data are probably quite indestructible due to this technology.

StratoSoar Glider Flies Itself From High Altitude

As the technology available to the average hacker and maker gets better and cheaper each year, projects which at one time might have only been within the reach of government agencies are inching closer to our grasp. Take for example the impressive work [Charlie Nicholson] has put into his StratoSoar series of autonomous gliders.

Dropped from several thousand feet by a high-altitude balloon, the glider’s avionics are designed to either guide it along a series of waypoints or head directly towards a specific target. Once at the given coordinates it can initiate different landing programs, such as spiraling down to the ground or releasing an onboard parachute. It’s an ambitious combination of custom hardware and software, made all the more impressive by the fact that it’s been put together by somebody who’s not yet old enough to have a driver’s license.

[Charlie] originally experimented with developing his own airframe using 3D printed components, but at least for now, found that a commercial off-the-shelf foam glider was a more practical option. All that’s required is to hollow out some areas to mount the servos, battery, and the avionics. This takes the form of a custom PCB that contains a ATSAMD21G18 microcontroller, an ICM-20948 inertial measurement unit (IMU), connections for GPS and LoRa modules, as well as several onboard sensors and some flash storage to hold collected data.

The goal of this open source project is to make these sort of unmanned aerial vehicles (UAVs) cheaper and more accessible for hobbyists and researchers. Eventually [Charlie] hopes to offer kits which will allow individuals to build and operate their own StratoSoar, making it even easier to get started. He’s currently working on the next iteration of the project that he’s calling StratoSoar MK3, but it hasn’t had a flight test yet.

We’ve seen various attempts to launch autonomous gliders from balloons in the past, but none from anyone as young as [Charlie]. We’re eager to see the StratoSoar project develop, and wish him luck in future test flights.

Continue reading “StratoSoar Glider Flies Itself From High Altitude”

Against Elitism

A while back we got an anonymous complaint that Hackaday was “elitist”, and that got me thinking. We do write up the hacks that we find the coolest, and that could lead to a preponderance of gonzo projects, or a feeling that something “isn’t good enough for Hackaday”. But I really want to push back against that notion, because I believe it’s just plain wrong.

One of the most important jobs of a Hackaday writer is to find the best parts of a project and bring that to the fore, and I’d like to show you what I mean by example. Take this post from two weeks ago that was nominally about rescuing a broken beloved keyboard by replacing its brain with a modern microcontroller. On its surface, this should be easy – figure out the matrix pinout and wire it up. Flash in a keyboard firmware and you’re done.

Of course we all love a good hardware-rescue story, and other owners of busted Sculpt keyboards will be happy to see it. But there’s something here for the rest of us too! To figure out the keyboard matrix, it would take a lot of probing at a flat-flex cable, so [TechBeret] made a sweet breakout board that pulled all the signals off of the flat-flex and terminated them in nicely labelled wires. Let this be your reminder that making a test rig / jig can make these kind of complicated problems simpler.

Checking the fit with a 3D printed PCB

Once the pinout was figured out, and a working prototype made, it was time to order a neat PCB and box it up. The other great trick was the use of 3D-printed mockups of the PCBs to make sure that they fit inside the case, the holes were all in the right places, and that the flat-flex lay flat. With how easily PCB design software will spit out a 3D model these days, you absolutely should take the ten minutes to verify the physical layout of each revision before sending out your Gerbers.

So was this a 1337 hack? Maybe not. But was it worth reading for these two sweet tidbits, regardless of whether you’re doing a keyboard hack? Absolutely! And that’s exactly the kind of opportunity that elitists shut themselves off from, and it’s the negative aspect of elitism what we try to fight against here at Hackaday.

Raspberry Pi RP2350-E9 Erratum Redefined As Input Mode Leakage Current

Although initially defined as an issue with GPIO inputs when configured with the internal pull-downs enabled, erratum RP2350-E9 has recently been redefined in the datasheet (page 1341) as a case of increased leakage current. As it is now understood since we previously reported, the issue occurs when a GPIO (0 – 47) is configured as input, the input buffer is enabled, and the pad voltage is somewhere between logic LOW and HIGH. In that case leakage current can be as high as 120 µA with IOVDD = 3.3 V. This leakage current is too much for the internal pull-up to overcome, ergo the need for an external pull-down: 8.2 kΩ or less, per the erratum. Disabling the input buffer will stop the leakage current, but reading the input requires re-enabling the buffer.

GPIO Pad leakage for IOVDD=3.3 V (Credit: Raspberry Pi)
GPIO Pad leakage for IOVDD=3.3 V (Credit: Raspberry Pi)

The upshot of this issue is that for input applications, the internal pull-downs are useless, and since PIO applications cannot toggle pad controls, the input buffer toggling workaround is not an option. ADC usage requires one to clear the GPIO input enable. In general any circuit that relies on floating pins or an internal pull-down resistor will be affected.

Although this should mean that the affected A2 stepping of the RP2350 MCU can still be used for applications where this is not an issue, and external pull-downs can be used as a ‘fix’ at the cost of extra power usage, it makes what should have been a drop-in replacement a troubled chip at best. At this point there have still been no definite statements from Raspberry Pi regarding a new (B0) stepping, leaving RP MCU users with the choice between the less flashy RP2040 and the buggy RP2350 for the foreseeable future.

Header: Thomas Amberg, CC BY-SA 2.0.