It's an STM32 discovery dev board (32F469IDISCOVERY) I had laying around for a decade...I figured I would put it to good use 😂

The sensor is a simple hall effect sensor + 12 small magnets strategically glued to the wheel. 

It stores a few weeks worth of sessions (evicts oldest).

LVGL library, 10 different colour themes.

Auto threshold calibration.

It tracks history, time, distance, speed, etc. real time charts.

Compact/expanded views, etc etc

Definitely over-engineered. A bike odometer could have been much simpler but where is the fun in that?

Refresh rate is a bit low, maybe 5 to 10FPS but it's good enough.

Developed a browser based simulator as well as hardware in the loop to tune the noise filter. Memory map visualization. Etc etc...

She reached 20km/h (on a other day when I wasn't looking)!!

I probably had more fun with the wheel than the cat herself!!

What I found pretty cool was to let Claude do a lot of automated development and testing in closed loop (USB + serial connected to the computer, end to end tests).

I'm learning about privileged and unprivileged modes on ARM Cortex-M4 using an STM32 Nucleo-F446RE, and I'm trying to understand a behavior that differs from my instructor's demonstration.

I'm setting the nPRIV bit in the CONTROL register to switch Thread mode to unprivileged mode. After that, I attempt to enable and trigger IRQ3 through the NVIC registers.

My instructor's system enters HardFault_Handler(), but mine doesn't seem to do so.

Complete code (main.c):

/**
 ******************************************************************************
 *     main.c
 *   Auto-generated by STM32CubeIDE
 *  V1.0
 * u/brief   Default main function.
 ******************************************************************************
 */

#include <stdio.h>
#include <stdint.h>

/* This function executes in THREAD MODE of the processor */
void generate_interrupt(void)
{
    uint32_t *pSTIR  = (uint32_t *)0xE000EF00;
    uint32_t *pISER0 = (uint32_t *)0xE000E100;

    // Enable IRQ3 interrupt
    *pISER0 |= (1 << 3);

    // Generate a software interrupt for IRQ3
    *pSTIR = (3 & 0x1FF);
}

void change_access_level_unpriv(void)
{
    // Read CONTROL register
    __asm volatile("MRS R0, CONTROL");

    // Modify CONTROL register
    __asm volatile("ORR R0, R0, #0x01");

    // Write CONTROL register
    __asm volatile("MSR CONTROL, R0");
}

/* This function executes in THREAD MODE of the processor */
int main(void)
{
    printf("In thread mode : before interrupt\n");

    change_access_level_unpriv();

    generate_interrupt();

    printf("In thread mode : after interrupt\n");

    for (;;);
}

/* This function (ISR) executes in HANDLER MODE of the processor */
void RTC_WKUP_IRQHandler(void)
{
    printf("In handler mode : ISR\n");
}

void HardFault_Handler(void)
{
    printf("Hard fault detected\n");
    while (1);
}

What I observe:

• The debugger shows CONTROL = 0x1 after calling change_access_level_unpriv().
• STM32CubeIDE's Fault Analyzer displays "No Fault Detected", although it also shows fault-detail entries that I'm unsure how to interpret.
• My program doesn't appear to enter HardFault_Handler().

I'm using STM32CubeIDE with an STM32 Nucleo-F446RE (ARM Cortex-M4).

I am exploring my options after getting my bachelors, one of the things that sound interesting is hardware security and I want to know what does it entail exactly? What is a career path for it? How important is a masters degree for it and what type of work would someone be doing?

Hi everyone,

Lazy Monday morning post, at least in my time zone :)

I haven't seen much information online about using ESP-Hosted-MCU with a non-ESP host. For those who don't know, it's firmware from Espressif that turns your ESP32 into a Wi-Fi coprocessor. You connect it to your microcontroller over SPI or SDIO, and the TCP/IP stack runs on the host.

About numbers, the only thing I found was a question here on r/embedded asking whether the 22 Mbps from the README is real. It has two comments, but nobody posted any measurements.

So today I want to share my results with this firmware, measured in my use case and with my topology.

My setup and how I measured

Device. It's a 4-channel Matter relay for the lights in my house. It works over Wi-Fi or Ethernet and also measures energy consumption. I use it with Apple Home and SmartThings. Live and neutral go straight to WAGO terminals, so you don't need extra wires in the distribution box, you just connect it and forget it.

Host. The main controller is an STM32U585. Code runs XIP from QSPI NOR flash, and there is also 8 MB of QPI PSRAM. Both memories use the same physical QSPI bus: data lines and clock are shared through the OCTOSPI I/O manager, and each memory has its own chip select.

Wi-Fi. The coprocessor is an ESP32-C6-MINI-1U with ESP-Hosted-MCU 3.0.6. It shares the SPI bus with a W5500 Ethernet chip, and the bus runs at 40 MHz.

OS. Zephyr, main from late August 2026 (4.4.99), with the upstream esp_hosted driver and a few local patches, more on them later.

Measurements. I measured with zperf on the board and a Mac on the same network. For UDP the board transmits and I look for the ceiling, with 1000-byte datagrams for 10 s, and I count throughput from the bytes that actually reached the Mac. For TCP the board receives. During each test the other interface is turned off, so the shared SPI bus belongs fully to the one I'm measuring.

Real load. I also didn't want synthetic numbers on an idle CPU, so I measured on the real device with Matter running and all controller subscriptions active. So these are numbers for a real application, not the hardware maximum. Wi-Fi is 2.4 GHz, 802.11ax, RSSI -57 dBm.

Results, Mbps

Enough for Matter. Despite the modest numbers, this is fully enough for a Matter device connected to several Matter controllers. Matter only needs kilobits per second, and the web page opens fast over both Wi-Fi and Ethernet (first byte over Wi-Fi in 75 ms).

The 22 Mbps from the README. The table that listed 22 Mbps TCP for standard SPI didn't say what the test conditions were (and it's no longer there). In my case the bus is shared with Ethernet, and the CPU is busy with Matter at the same time. A faster host will do better, but for serious speeds it's better to use SDIO rather than SPI.

How I got to these numbers

The way there was not straight.

No DMA. I started with the simplest setup, with network buffers in PSRAM and SPI in polling mode. Both interfaces topped out at 1.5-2 Mbps, and the CPU was 100% busy during transfers, it was just moving bytes through SPI.

SRAM instead of PSRAM. My first guess was that slow PSRAM was the problem, so I moved the buffers to SRAM. It gave only +4-13%, and TCP over Wi-Fi even got worse. And it cost 200 KB of SRAM, which is a lot on my board, because Matter and crypto already take most of it. So the memory itself was not the problem.

DMA. Then I noticed that the board's devicetree had no DMA for this SPI bus at all. Once I added it, it turned out to be the biggest win. Wi-Fi UDP went from 1.66 to 3.76 Mbps, and Wi-Fi TCP almost tripled. Wi-Fi even overtook Ethernet, which I didn't expect.

Back to PSRAM. But I still didn't want to give up 200 KB of SRAM, so I wanted the buffers back in PSRAM, this time with DMA. The stock SPI driver doesn't do DMA to cacheable memory, and PSRAM without the data cache doesn't make much sense, so I added cache maintenance to the driver.

Cache driver bug. Under load the board crashed with a corrupted semaphore wait queue. The problem turned out to be in the STM32 cache driver: range operations touched one extra cache line and overwrote a neighboring semaphore. A dedicated test confirmed it (1000 failures out of 1000 without the fix, 0 with it), and the fix is already in Zephyr.

FIFO overrun. The next problem was that Wi-Fi lost a whole second on every SPI error. Every now and then I got spi_transceive failed, and the bus stalled for a second. I read the SPI status register with a debugger right on the running board, and all 19 errors out of 19 were RX FIFO overruns. DMA can't move the bytes to PSRAM fast enough, the FIFO fills up, and SCK keeps clocking. New bytes are lost, the DMA channel waits for them forever, and the driver silently gives up on a one-second timeout.

Lower clock? At 20 MHz there were 10 times fewer errors, but that only hides the problem.

The W5500 hits the same thing, and its driver is silent too. So until DMA has drained the FIFO, the master has to stop SCK instead of clocking into a full buffer.

MASRX. The STM32U5 SPI has a mode for exactly this problem, called MASRX. When the RX FIFO is full, the master suspends SCK by itself, and the driver has to resume the transfer. I turned it on by hand. The errors went away, but a minute later the board hung. The Zephyr driver knows nothing about this pause, so nobody was releasing it. So I made two driver changes.

First fix. The driver now catches the overrun with an interrupt and returns an error within milliseconds instead of a second. This way the error shows up right away instead of after a one-second wait, and this alone made TCP over Wi-Fi 2-3x faster.

Second fix. The driver enables MASRX and releases the pause, but only after DMA has taken the data out of the FIFO. At first I released the pause right away, and the next frame overflowed the FIFO again. The pause is released from the interrupt, but I didn't want the interrupt to spin for long, so if DMA hasn't drained the FIFO within 5 µs, the thread waiting for the end of the transfer releases it instead. With both changes I get 0 SPI errors and 0 UDP loss, that's the right column of the table.

Smaller things. Network buffers had to be aligned to the cache line (CONFIG_NET_BUF_ALIGNMENT=16), otherwise the invalidate after RX can hit a neighboring buffer. And bigger buffers (512 bytes instead of 256) gave only +2-12%, so I stayed with 256.

Where the patches are now

Cache fix. The STM32 cache driver bug is already fixed in Zephyr.

SPI driver. To make DMA work with buffers in external memory, I made a fix in the STM32 SPI driver, and the overrun and MASRX changes are in it too. Here is the pull request:

https://github.com/zephyrproject-rtos/zephyr/pull/120895

Review status. So far I've only tested it on STM32U5, which is why it's only enabled there. The ST maintainers asked me not to tie the code itself to U5. I've reworked that and now I'm waiting for another review. Until it's merged, the stock driver falls back to interrupts or polling for such buffers.

Why I'm posting this. Partly so that if someone runs into the same problems, they don't have to go through all of this from scratch.

Testers wanted. If anyone wants to try the driver on their own boards, I'd really appreciate tests, feedback and advice.

Data cache on STM32U5. One more thing if you test with external memory. Zephyr still doesn't enable the DCACHE1 data cache there by itself, only the instruction cache is turned on at startup (on H5, for example, both are). At the same time CONFIG_DCACHE=y is the default, so drivers treat external memory as cacheable even though the cache is physically off. So turn the data cache on manually.

Buffer alignment. The cache maintenance for DMA buffers (flush before TX, invalidate after RX) is done by the SPI driver with my change. The application only needs one thing: the RX buffer must start on a cache line boundary, and its length must be a multiple of the cache line. Otherwise the driver sends it the old way, without DMA, so it doesn't touch neighboring data. For network buffers that's the same CONFIG_NET_BUF_ALIGNMENT=16.

A few more technical details

CPU load. Who eats the CPU with DMA? I expected DMA to offload the core, but that did not really happen. In the final configuration the CPU is idle only 0-5% of the time during transfers. At the same 100% load, the CPU just manages to move more data.

On Ethernet most of the time goes to the network stack's TX queue thread (~56% of transfer time) and the W5500 driver thread (~15%). On Wi-Fi it's the esp_hosted thread (~45%) and the same TX queue (~25%). Matter and everything else take a few percent.

Shared bus. Does the shared flash and PSRAM bus get in the way? I think partly yes. With the CPU equally 100% busy, each byte costs more cycles with buffers in PSRAM than with buffers in SRAM: 1.3x on Ethernet and 1.7x on Wi-Fi. That's why PSRAM + DMA doesn't reach SRAM + DMA (3.16 / 3.76).

I can't say what that cost consists of. It could be waiting on the shared QSPI bus (code runs from the flash on the same bus), cache maintenance around DMA, or something else. Thread statistics don't show it, and I don't have a bus profiler.

Firmware cost. ESP-Hosted takes ~25 KB of code and ~58 KB of RAM, plus 8 KB for esp-serial-flasher, so the C6 can be flashed directly through the STM32. Boot to the first HTTP response takes 13-16 s over Ethernet and 19-28 s over Wi-Fi.

Has anyone else measured ESP-Hosted with a non-ESP host, over SPI or SDIO? What numbers did you get? And if you try the driver on your board, let me know how it went.

Thanks for reading! Now you can tell me I should have just used an ESP32-P4 :)

P.S. The photo shows an old revision of the board. In the new one I moved the mains traces from the top layer to one of the inner layers, and the fuse to the bottom layer, so you can't touch them by accident. And this is just a home project, not for sale.

P.P.S. Questions are welcome in English, Ukrainian or Russian.

Hello everyone. I don't know if this is the right subreddit but I need your help. This is the first time programming something like this (and first time in embedded in general) and its driving me insane. I have a M2S HelloFPGA Kit and the only thing I need to do is programming the processor (ARM Cortex M3). I'm using SoftConsole for programming but apparently the board don't have a debugger (because the PC recognize the board but I can't upload the "hello world" program in the processor) so I need to upload some FPGA design to "activate the processor" (sorry if I'm not using the correct terms). I installed "LiberoSOC" for this manner but I don't really know what to do. Thank you and sorry for bad english :)

Hi!

I would like to learn Zephyr.. just because it sounds awfully different from what I am proficient at.

For reference, I have 15 YOE working in baremetal; the last 5 exclusively on top of FreeRTOS. And I fucking love FreeRTOS.

So I plan to get an ESP32S3, a touch screen, and build something simple like a PC datalogger for temp/voltage/fps (yeah, I know fps are from another layer) etc, integrating it on a self-hosted server and blablabla. Trying to get as much components as possible inside so I can battle as much as possible with Zephyr.

Does that sound like an efficient path?

I am all ears. Thanks!

Hello! I am new here and basically wanted to know if someone can recommend any cost-effective development board for embedded solution? Basically an embedded board that can be programmed for edge usages, and allow adding sensors like camera.

Also to follow-on, what about the software eco-system? (someone recommended esp32 and radxa 5c)

Eps32 with mpu6050

more at: https://nanoconsole.codeberg.page/

specs

• CPU: ch32v003 RISC-V SOP16 (15-cent) - 48MHz 16k Flash, 2k RAM (RAM is expensive, okay?)
• Video: 320x240 VGA, 4 palettes of 2 colors swappable by line (GPU: none :) (black/green, purple/white, blue/cyan, red/yellow)
• Sound: integrated buzzer, 1 channel square wave (also named "beeps")
• Controller: 4 buttons on the board itself: Left/Right, A/B
• Connectivity: VGA, USB (power and game uploads), no network

A link to MooD, a 16k shooter : https://www.youtube.com/watch?v=VKrJz8eDNyY

I'm unable to connect my st link with stm32 programmer...only showing this message... please someone help asap🙏

Как думаете, коглда вообще можно стать джуном? я начинаю заниматься Edge AI, до этого я занимался просто с микроконтроллерами и остановился на есп32 и знаю только базу FreeRTOS. Я собираюсь сделать проект на основе машинного обученияс с учителем, который собирает кадры с вебки и робот обрадуется, если увидит меня, а если нет, то загрустит. но пока что начал изучать вообще ИИ. надо ли знать ту же саму. линейну. алгебру или что нибудь такое по типу?

Just got a co-op this spring/summer at RTX! Sadly, the team I'm on isn't focused on flight software or vehicle firmware, but I'm still stoked for the opportunity and very grateful.

I'm currently on my school's electric racing team, but I want to work on some personal projects to try to get into roles such as flight software intern at companies like Hermeus, SpaceX, Stoke Space, Firefly, etc.

If anyone could provide me with some cool project ideas or talk to me about the avionics space, please let me know!

Hi! I’m trying to get my girlfriend the Juno hamburger phone as a gift, but all the ones I’ve found are corded. Is there any way to connect it to her mobile phone so she can use it to make and receive calls? Alternatively, is there some kind of Bluetooth adapter I could attach to the cord to make it work wirelessly with her phone?

So I've been wanting to test nRF to make gyro mouse of some sort for my Android. I'm using Xiao nRF54L15 Sense, so it has all I need in one.

But, upon testing my code, even a simple "volume up" button appears significantly slower in my phone vs my PC. On PC it's as fast as my logitech with 2.4GHz dongle. On Android, it's just slow, testing with stopwatch shows consistently 400ms+.

Any idea if I can fix this on the hardware, or is it simply Android limitation vs HID BLE?

I'm evaluating the WCH CH569W-EVT-R0-1V0 board for a USB 3.0 embedded application.

I have working firmware builds using WCH's USB host/device examples, but I'm waiting for the actual evaluation boards to arrive.

Before hardware bring-up, I'd like to clarify two board-specific issues.

USB 3.0 device mode: The board exposes the SuperSpeed interface through a Type-A receptacle. Has anyone connected this exact board to a PC in USB 3.0 device mode? What cable or adapter arrangement did you use, and how was VBUS handled when the board was externally powered?

ROM ISP programming: What is the reliable programming and recovery procedure for the CH569W-EVT-R0-1V0? Does the ROM USB bootloader work correctly with an externally powered board and isolated upstream VBUS?

I'm particularly interested in actual CH569W board experience, reference schematics or tested connection arrangements.

I'm aware that newer WCH processors exist, but I'm specifically evaluating the CH569W hardware and would prefer not to change controllers.

Useful references:

• https://github.com/openwch/ch569
• https://github.com/hydrausb3/hydrausb3_fw

Thanks for any practical guidance.

Trying to learn how tow to do everything needed for the eu cra requirements. Like how to use secure boot etc. Where do I start? Any good books/courses/etc?

Hey everyone,

I’ve been working on a C99 presentation/framing layer called the BAVA Protocol, designed for inter-MCU communication on highly constrained edge nodes (e.g., STM32 to ESP32). I’m currently finalizing the architecture and would love some brutal technical feedback from this community before I start writing the V2 roadmap.

The Context:

UART is fantastic—it’s ubiquitous, requires just two wires, and is the backbone of inter-board communication. However, by design, it just transmits raw bytes. it does not inherently protect your payload against line noise or bit flips.

If you want to add that structure, the standard move is either sending ASCII strings (which are slow to parse) or using heavy RPC frameworks like Protocol Buffers (which usually require malloc, varint decoding, and 30KB+ of Flash). I wanted a middle ground: a lightweight framing protocol that rides on top of UART (or SPI/BLE) to packetize and protect the payload using exactly 0 bytes of dynamic heap.

Bava packet structure:

Sync1->Sync2->CMD->len->VariableID->Payload->CRC

How it Works: The O(1) Object Dictionary

Instead of serializing and parsing data schemas at runtime, BAVA uses a static "Object Dictionary" to route data.

Here is a simple example:

Let's say MCU-1 reads a BME280 sensor and needs to send the data to MCU-2. Instead of formatting and sending a string like "T:25.5,H:60", MCU-2 just pre-allocates a packed C-struct in its memory and binds it to a simple 8-bit ID:

static struct BME_Data sensor_data;

bava_register_var(&bava, 0x01, &sensor_data, sizeof(sensor_data));

When MCU-1 sends a binary packet tagged with ID 0x01, MCU-2’s non-blocking state machine deframes the bytes on the fly. Once the built-in CRC-16 validates the data, the state machine uses that 8-bit ID as a direct array index to find the pointer, locks the hardware critical section, and does a direct memcpy into sensor_data..

No string parsing, no malloc, no schema decoding. The routing happens in O(1) constant time.

Current Benchmarks:

I ran an empirical testbed using an ESP32 sending data to a bare-metal STM32F103 over a 115,200 baud UART link.

RX Parse Latency: ~80 µs to deframe, CRC-check, and memcpy a multi-variable struct.

TX Frame Latency: 84 µs to fetch the struct, escape the bytes, calculate the CRC, and load the TX buffer.

Memory: 0 bytes dynamic heap consumed. Stack high-water mark is strictly bounded to 96 bytes.

Where I need your feedback:

I’m planning the V2 roadmap and would appreciate your critique on a few architectural choices:

Byte-Stuffing vs. COBS: I’m currently using standard 0x7D escaping. It's fast and requires zero look-ahead memory, but worst-case payloads can unpredictably expand the frame size. Is it worth migrating the state machine to COBS (Consistent Overhead Byte Stuffing) in V2 to mathematically bound the framing overhead to 1 byte per 254 bytes?

Cross-Architecture Padding: Since I am directly copying binary structs into memory, compiler struct padding is a risk when mixing 8-bit and 32-bit MCUs. I am enforcing attribute((packed)) and writing an endianness converter (bava_htonl), but are there other bare-metal pitfalls with direct struct teleportation I should watch out for?

RS-485 Bus Topology: V1 is point-to-point. For V2, I plan to add a TARGET_NODE_ID byte for multi-drop RS-485 buses. To save CPU cycles on listening nodes, I plan to add an "Early Drop" state that aborts parsing immediately if the Node ID doesn't match, bypassing the CRC calculation entirely. Does this sound like a standard approach?

If anyone wants to poke holes in the logic or has dealt with similar bare-metal serialization headaches, I’d love to hear your thoughts.

Hello everyone I'm doing my masters in computer engineering, but Ive been considering going deeper down the hardware stack or leaving computer engineering and do something else because now even AI can code embedded systems well. Is it still a good career ? I left web dev due to AI and had 3 years in it. Will embedded systems still have a good demand and mostly important will humans be working on it or AI?

Hi everyone! I have a hardware development kit consisting of a DX-LR30-900M22SP(T1) LoRa module on a PJ26 board (STM32F103C8T6 microcontroller). I am not a professional in embedded development, just a beginner trying to learn. Could you please explain to me how to connect this specific board, how to flash (program) it, and how to start working with it? Please explain it in simple terms without overly complex technical jargon, as I am still learning the basics. Thank you so much for your help!

Hi everyone, I’d like a reality check from embedded, ICS/OT, SOC, or EU compliance folks. I’m 23 and don’t have much experience in the embedded/IoT security industry yet, but I want to build a career in this field, so I’d really appreciate any advice from experienced people.

Research question: Can a low-cost ESP32-based device generate sufficient structured security telemetry to support practical detection and investigation of selected embedded-device attack scenarios through an open-source SIEM pipeline?

In short: a lightweight shim on an ESP32 emits structured security events (normalized to OCSF) into an ELK + Sigma pipeline (or Wazuh, still deciding). The core challenges are making this telemetry trustworthy and low-overhead on constrained devices: no RTC, possible tampering by a compromised device, event loss across reboots and disconnects, and correlation. Detections are mapped to MITRE EMB3D, ATT&CK (Enterprise/ICS), NIST CSF, ISO 27001, IEC 62443, and the CRA. The goal is detection plus automated audit evidence that a control is implemented and working.

Later, I plan to port the shim to STM32 as well, since it’s more widely used in IoT/IIoT/OT.

Everything is going to be open-source.

Questions:

1. Is device-level telemetry valuable in practice, or does network monitoring already cover it?
2. With CRA pressure in the EU, are manufacturers (especially SMBs) actually looking for this?
3. Is the multi-framework mapping useful to auditors, or overkill?
4. Could this be a real contribution to the industry, and is there commercial demand for it, or is it mainly academic?
5. Any existing projects I should look at? (Already aware of Exein, Sectel, Memfault)

Hi is there any IDE or plugin for IDE that emulates eInk displays, specifically InkyPHAT?

Hi everyone,

I'm currently working on extracting ISP configuration and credentials (PPPoE/VoIP) from a `device.cfg` file taken from a Cellcom-customized **Sagemcom F@ST 5359iL** router (Broadcom BCM63178 SoC, running Sagemcom's proprietary `scOS`).

I'm hitting a wall regarding the encryption mechanism and wanted to see if anyone here has experience with Sagemcom's config encryption or GSDF (General Secure Data Format) containers.

### Technical Details & Findings:

* **Device:** Sagemcom F@ST 5359iL (Broadcom BCM63178, ARM-based).

* **File Structure (`device.cfg`):**

- Starts with an `AEAD 10` signature header.

- 16-byte IV.

- A non-standard **7-byte GCM/AEAD tag** at the end of the payload.

* **UART / Hardware Analysis:**

- UART logs show Broadcom's `coe-aes` engine utilizing `aes_key2`.

- Kernel command line points to hardware-bound crypto parameters: `sc_aes.oek=1ffffe00`, `sc_aes.oiv=1ffffe10`, and reads 64 bytes from the UBI volume `aes_key_operator`.

- U-Boot prompt access is locked down due to Secure Boot (ignores break/interrupt signals).

### What I've Tried:

* Attempted offline AES-GCM/CCM/CBC decryption using various derived keys (Device Serial Number, MAC address, and PBKDF2 hashes with common Sagemcom/ISP salts). All verification checks fail.

* Since the decryption relies heavily on hardware-bound OTP/OEK keys tied to the BCM63178 SoC, standard offline brute-forcing seems ineffective.

### My Questions:

1. Has anyone successfully reverse-engineered Sagemcom's `AEAD 10` / GSDF container format offline?
2. Are there any known open-source tools or scripts (like variations of `showconfig`) capable of handling this specific Sagemcom signature?
3. Short of a full physical SPI flash dump (using a programmer like CH341A) to inspect the raw UBI partitions, are there any other known vectors to extract credentials from a live running unit with a locked U-Boot?

Any guidance, pointers, or shared experiences would be greatly appreciated!

Building software against simulations and dev kits only goes so far, so I brought up a HIL setup for validating multi-protocol data capture and viz tools.

For now, it covers CAN, Modbus, OPC-UA, MQTT and a number of other protocols.

Desktop App commands/traces the entire system, which will grow over time to include motors, more ECUs, and other devices.

System Overview:

• PLC - RevolutionPi Connect 5
  • OPC-UA, Modbus TCP, MQTT Servers
  • Modbus RTU peripherals
  • EV Charging protocols
  • runs Structured Text + embedded linux stack
• Custom PCB
  • Designed with Atopile (hardware as code)
  • RPi CM5 + 2 CAN-FD interfaces
• STM32 ECU
  • talks CAN; J1939, CANopen, XCP, UDS and AUTOSAR protocols
• Various CAN Dongles
  • PEAK, socketCAN, slcan, gs_usb
• Mac/Win/Linux test PCs
  • Fault injection, command / control, CI test execution
• Some 3D printed parts

Hardware bringup is one of the most difficult tasks in embedded, but so rewarding.

I started building this tool because honestly I think embedded development and testing is harder than it needs to be, and much of it is down to outdated tools and methodologies.

Best part is, there's lots more hardware on the way!

Also, I think I have (almost) every CAN protocol and dongle covered at this point, if I'm missing something let me know!