First design in KiCAD 8. Super simple design done in one evening, just a pair of STM32L431s with some connectors and bypass caps, a SPI bus between them, and a QSPI flash hanging off one.
4 layer board with components on top side only. Another rare "no FPGA" design - I seem to be doing more of these small/quick test or accessory boards lately.
This one is essentially a power failure fuzzer for MicroKVS (https://github.com/azonenberg/microkvs) to make sure that interrupting it at any point will lead to writes atomically succeeding or failing, and never corrupt data. The test controller MCU (left) controls reset and power gating to the DUT MCU (right) and will be resetting and/or power cycling it at random intervals during testing. The DUT, meanwhile, will be constantly reading and writing simulated configuration data to flash and reading it back, and complain if anything fails.
It's also going to serve as a testbed for external quad SPI flash on STM32L4 (and STM32 in general) for MicroKVS.
@jpm The L431 is one I already have existing peripheral library support and software stack etc for.
My use case for this specific test is mainly "I need more flash than a L0 and the ability to test page-writable ECC flash without spending H7 level budget on a board I plan to test to destruction repeatedly, then swap the micro and go again".
In all seriousness, I'd love if anyone had a better solution to this problem. But there doesn't seem to be any SFR bit I can set to make the STM32H7 flash IP not throw a bus fault on an ECC failure.
So if you ever have a bug in your firmware that writes to the same flash ECC block twice without erasing it, that flash block will become toxic and any future attempt to deref any address within it will segfault. Not good if you're trying to make a robust, log-structured data store (in which any bug or unexpected power cycle poisons the entire key-value store, segfaulting future reads).
Turning off faults when writing, or when doing CRC checks on read data, allows graceful degradation when things go wrong.
Still trying to figure out why the bootloader seems to be stepping on non-blank flash cells (it should be appending at the end), but at least it's not soft-bricking the board by throwing the bootloader into a fault handler before it reaches the DFU flow.
@azonenberg@dok So, in a sense, it was working as intended and notifying you that the flash had been corrupted. 😉 At Netapp we had NVRAM that would hold the current checksums when we had a raid stripe "open" (it was being modified but had not yet been committed).
@ChuckMcManis@dok It was working as designed but blocking my intended error recovery path.
The whole point of the log structured design was thst if you corrupt an older version of an object it doesn't matter, and if you corrupt the newest version it cleanly falls back to the previous.
Crashing any time you walk the data structure looking for the most recent intact version of the object wasn't on the menu :)
Today I learned (the hard way) what happens when your bootloader pushes firmware to flash one ELF program header at a time.
And your flash controller requires 64-bit aligned writes.
And that the GNU LD ". = ALIGN(foo)" directive only aligns the virtual address of the section, not the physical address in the binary. To get that aligned, you need to do ".data : ALIGN(16)".
Well, looks like it's doable! I have a draft pinout for the STM32H735 that hooks up one quad SPI channel to a flash chip, parallel trace, plus three different interfaces to an FPGA:
Octal SPI + DQS
FMC configured as 16 bit multiplexed PSRAM
RMII
Still have to figure out what other peripherals, if any, to hook up. This is mostly just a testbed for MCU-FPGA communications to see what interface I want to use for my next big embedded project, it won't actually do anything useful.
But if I can test as many things as possible, that will help avoid the need for more sandbox boards in the near future.
This little guy is 3.2 x 2.8mm footprint, fully self contained except for external capacitors and a single resistor to set the output current. Up to 17V input, 0.6-5.5V output, 3A load capacity.
Not enough output current to replace the Murata modules I use now for heavy stuff, and ripple is a bit worse.
But for less sensitive, lower power applications I could totally see sprinkling these around a lot of my designs.
Continuing with the board design, this will be my first use of the STM32L081 in a design as a power/reset supervisor.
It's got a lot more memory than the L031 I usually use for this purpose (192 kB flash / 20 kB RAM vs 32 kB flash / 8 kB RAM) which should allow a full bootloader + A/B firmware image flow for field updateability (one of the things I want to validate in this design).
Interestingly, despite being in the same 32-pin QFN as the L031, it's not pin compatible.
Also interesting is that there's a VDDIO2 pin that supplies pins PA11 and PA12. I'm not sure why they did this, these pins don't even have any interesting peripherals like a UART or I2C bus on them. And only two GPIOs is a little light compared to having, say, half the IOs on one bank and half on another.
What's the go-to option for RGB status indicator LEDs that contain an integrated controller so I can control a lot of them from a handful of pins? Are people still using the WS2812 or are there better options these days?
For my embedded projects my requirements were "key-value store for binary data", "usable on a tiny cortex-m0", "smallest flash usage possible", and "resilient to power failures, resetting the chip at any point including during a write cycle should result in writes atomically succeeding or failing".
This ended up leading to the creation of my MicroKVS project which is optimized for small code size and minimal flash usage at the expense of speed, and uses the smallest amount of flash theoretically possible while still providing power loss protection (two flash erase blocks) unless you explicitly ask for more space to store larger amounts of data.
First light on the Thunderscope beta after grabbing an upstream driver fix. There's definitely some rough edges I'm going to need to fix before it hits production, but I'm really excited - it's FAST!
With ngscopeclient running directly on the laptop the scope is plugged into (i9-10885H, Debian Bookworm, Quadro RTX 3000) I get 17 WFM/s for 4 channels @ 250 Msps with 10M points memory depth. That's 680 Ms/s (out of a theoretical 1000 coming off the ADC). At 8 bit sample size that's 5.44 Gbps, around double my previous record (PicoScope 6824E).
With the TS.NET bridge server on the laptop and a 10GbE Thunderbolt dongle connecting the laptop to my LAN, then ngscopeclient running on my main bench workstation, I "only" get 7-10 WFM/s - about half speed and competitive with the PicoScope.
There's likely room to optimize all of these numbers, this is just an initial sanity check.
So apparently Murata makes high power, fixed ratio (6A, divide by 4) 2-phase charge pump step-down converters intended for 48V -> 12V applications.
It looks to have higher efficiency especially at low loads than the TDK module I'm using now. Seriously considering making a variant of my IBC to try it out. Non-regulating but that should be fine given my use case (generating 12V intermediate rail which will itself be fed to other buck modules).
Anyone have thoughts? I've always thought of charge pumps as ittty bitty things you use when you need a negative bias rail, not something you pull six amps from.
@0h00000000 I'm using a buck now, and certainly open to exploring other buck units as well.
But I'm specifically looking for integrated DC-DC modules (whether buck, charge pump, or other topologies) that have all of the passives and transistors included and just need external bulk caps.
When I have a dozen rails on a board I don't want to lay out SMPSes by hand every time. I'd rather just slap down a module and a few caps. The IBC is only a single channel but still, if I'm building a bunch of prototypes modules are less effort than throwing down a bunch of discretes.
Also usually lower risk in terms of a higher probability of a right-first-time design.
Was getting ready to do more trigger crossbar dev tonight, but realize the logical next step would be putting a bootloader and DFU support on the main MCU.
And that would involve a bunch of code copy-pasting.
So before I go any further I think I'm going to start librarizing my embedded platform to move all of the common infrastructure out into a separate repository.
There will probably be one baseline bit of code shared by literally everything, then extended versions of that for main processors running application firmware as well as for PMIC/supervisor platforms since I expect to be doing that a lot, and one for bootloaders.
Still beginning to think about how it's actually going to be architected, I have ideas but no firm details yet.
Starting to plan a new test board for my embedded platform to try a bunch more things I can't try or validate on the trigger crossbar. STM32H735 plus XC7S25 in FTGB196 since that's what I had lying around with enough block ram for plenty of ILA cores and comfortably routable on oshpark 4L (although I'm not yet sure if I'll be able to get all the STM32 signals out without going to a higher end process).
Probably won't have bench space to assemble it for a while, but I want to get it designed and ordered so that's out of the way.
Current plan (pinmux config permitting, I haven't done a pinout yet):
1GbE Ethernet interface to FPGA
RMII from MCU to FPGA
One octospi channel from MCU to FPGA with all DQ and DQS pins hooked up
Second octospi channel to a qspi flash
FMC from MCU to FPGA
STM32L081 as supervisor/pmic (enough flash to fit a bootloader)
Things I want to test here:
Ethernet MAC on the STM32H7
Using octospi DQS/DM for memory mapped writes with byte masking
Using FMC to map the FPGA as (a)synchronous SRAM with no caching
SSH DFU of supervisor MCU without causing a reset of the board (i.e. not sequencing rails off and on again when rebooting in DFU mode, although supervisor mode will probably be temporarily unavailable)
Putting microkvs data in external QSPI flash
Trying to think if this is good or if there's anything else I should try to test on the same board.
@azonenberg for shits and giggles, MicroKVS accelerator in the FPGA - content-addressable memory that can find any key and return its index/location in a handful of FPGA cycles instead of doing a sequential scan or b-tree walk of all the keys
@jpm Lol, not happening. The point here is not to spend a lot of time on feature development, it's to validate chip to chip interfaces for future PCB designs.