I’m trying to reverse engineer the firmware on a Krystel TV to figure out why it only stores 7 DVB-T TV channels (plus about 10 radio stations) despite scanning all UHF channels (21–48) successfully. The factory menu (code 1148) allows exporting rom.bin, Data_Backup.bin, ChannelTable.txt, and S2_UNIPLATFORM_CH_TABLE.json. The exported channel list only contains 7 services, and Data_Backup.bin contains strings like UK-24, UK-45, UK-69, and MI210528WHX001_WEIGAO_52CA63B, which makes me think there’s a region or service whitelist somewhere in the firmware. Has anyone seen the RR52C_A63B platform before or know how to analyse/patch these firmware files? Any advice on identifying the SoC, firmware format, or locating DVB-T configuration tables would be greatly appreciated.

Hey r/embedded,

I support a fielded product line built around the Toradex T30 Module— the NVIDIA Tegra 3 (quad Cortex-A9) SODIMM-style SoM, 68 × 37 mm Toradex has it flagged EOL / not-recommended-for-new-designs, and every normal channel is dry- as a "small" buyer we are not important enough to get real alternatives.. so im a littebit backed against a wall.

Honest Situation: We are already mid of migrating to a current module and had sized our last-time-buy accordingly (also a last last time buy). Then a customer came back with demand at a volume that's way outside anything we'd normally commit to support on an EOL part — far beyond what our remaining stock and the migration timeline can absorb. We're now under serious pressure to keep them supplied on the legacy hardware while the new design finishes cert. So this is a bridge-supply problem i am really at an dead end to solve. I called multiple refurbed shops here in Germany, tried 2nd source shops etc. Either we are with our demand of roughly 1000pcs too small or there is really no supply.

What I'm after:

• Toradex Colibri T30
• Target quantity: ~1000 pcs (optimal). Realistically I'll take whatever's out there — partial lots absolutely help and I'm happy to aggregate across multiple sources, if it helps our timeline.
• NOS preferred, but refurbished / tested pulls are fine if functional and verifiable
• EU / DACH preffered but i can handle worldwide also

Where I could use the hive mind:

• Brokers you've personally had good experiences with for legacy SoMs at volume (the space is full of bad actors, so first-hand recs matter a lot here)
• Anyone who over-ordered their own last-time-buy and is sitting on Colibri T30 stock and wants to get it off there shelves :)
• Decommissioned fleets, lab surplus, repair-shop pulls
• Refurbishers who can test-and-verify this class of module at quantity

Happy to pay fair market rate + shipping/testing, verified sellers only, and I'll take specifics to DM / a proper PO. Any lead — even "try this obscure shop" — is genuinely appreciated. Time-sensitive, so I'll respond fast... if my kids let me :'D

Eitherway: Thanks to the community!

BR

Hi everyone,

I'm trying to understand whether this is a known issue or if anyone has experienced something similar.

We are using LoRaNet LBM with Zephyr on the nRF54L15.

The problem is not limited to GNSS. We've seen the same behavior with GNSS, FUOTA, and also periodic uplink on the nRF52840.

The common point is that all of these are long-running asynchronous operations.

It seems that the interaction between the LBM Supervisor and the Zephyr scheduler/workqueue is not handling deferred or rescheduled operations correctly in some situations. If an operation cannot complete immediately and needs to continue later, the supervisor sometimes stops making progress and the application appears to freeze.

To work around this, we implemented our own defer/reschedule mechanism for GNSS, Wi-Fi scanning, and FUOTA so the supervisor can continue running while those operations complete asynchronously. That solved those cases, but we're wondering if there is an official or recommended way to handle this kind of integration.

Has anyone seen similar behavior when using LBM with Zephyr? Is there a recommended pattern for handling long-running asynchronous operations with the LBM Supervisor?

One of the freeze logs looks like this:

[01:04:27.361,834] <inf> smtc_modem: Sleeping for 60000ms
[01:04:27.494,532] <inf> smtc_modem:
[01:04:27.494,568] <inf> smtc_modem: EXPECTED MIC : 3F928286
[01:04:27.497,105] <inf> smtc_modem: gnss task launch at 21047366 for navgroup.scan[0]
[01:04:27.498,429] <inf> smtc_modem: rc : 0
[01:04:27.498,502] <inf> smtc_modem: RP: Abort running #2 for priority #0

Another freeze ends here:

[00:01:42.314,892] <inf> nav3_lbm: GNSS prescan actions - enabling LNA pin
[00:01:42.314,918] <inf> nav3_lbm: LNA pin enabled (HIGH)
[00:01:42.315,225] <inf> smtc_modem: Sleeping for 60000ms
[00:02:42.315,357] <inf> smtc_modem: Sleeping for 60000ms
[00:02:46.273,493] <inf> smtc_modem: gnss_rp_task

Any suggestions or insights would be appreciated.

Thanks!

Hey guys!
I’ve just opened the repo for my battery-friendly ESP32-C3 environmental node. The hardware is pretty basic, as I spent most of my time focusing on the firmware — skipped Arduino completely and built it on pure ESP-IDF v5.x + PlatformIO.
It’s got Deep Sleep with RTC wakeups, a SoftAP
Web Portal for live setup/calibration, and multi-channel alerts (Telegram/Discord/Webhooks).

The code is live on GitHub: https://github.com/d7main/ESP32_EnvironmentalNode
Would love some feedback on the C architecture, testing on real hardware, or PRs. Check it out!

Simulators are great for perception, but they completely miss the hardware-execution gap. How are you guys profiling power transients (dI/dt) and thermal throttling under real electrical loads? I'm building a local CLI to orchestrate this on custom PCBs because Isaac Sim doesn't catch melted silicon. Are you all just writing custom Bash scripts to poll JTAG

anybody ported it to work with latest stable uboot, buildroot and fsbl? i'm willing to use it for edge ml (image and audio)

Hello everyone,

Some context about my question. I worked in the Embedded SW field for 5 years now mainly in big corporations (focused on automotive) and now i am in a new position is a smaller company. It's a lot smaller in scope as we maybe make 100-500 pieces of any one product at best, custom made for the customers.

Coming from big corporation / automotive I see here that the testing side of our process is very weak. There is no real procedure and no dedicated equipment. I am used to work with the industry standard HiL rigs like dSpace, Vector and Speedgoat, that usually have entire departments setting them up for the products. At the new job most team usually just put together some development boards to do some high level testing at best.

The project I was hired for is Safety critical so we need reliable Test equipment, but when i brought up dSpace or similar my manager didn't even want to hear about such high costs. I also offered we can build something in-house, but again I've been told we don't have the money/time/people for it.

So I was wondering if any of you guys know of other cheaper Test rig alternatives? Main focus would be High level black box testing of a PCB with CAN, SPI, and some analog connectivity. The aim would be for it to have or easily adaptable for an automated test framework.

Any recommendations are welcome! (we are in the EU region)

Hello people!

I made a 2-axis gimbal for my drone and I have a problem where when the pitch axis is at a certain angle, the roll axis starts slowly drifting form it's initial angle.

Example: Pitch axis is set to 65 degrees and Roll to 0 degrees, everything is okay. But when Pitch axis is set to something like 80 degrees or above, the roll angle moves a little bit and from there starts to slowly drift the same direction until who knows how long.

I recalibrated the accelerometer but not the gyroscope, because the SimpleBGC program automatically calibrates it, if I'm not mistaken.
I did a bit of PID tuning, but PID doesn't seem to be the problem.

Maybe someone has had the same problem and/or knows how to fix it?

I'm using a SimpleBGC 32-bit Extended controller.
The 2 motors, that I'm using, are GM3506 with encoders.

How to connect 4S Lipo with JK BMS?

This is the link to the battery: Gens Ace G-Tech 4000mAh 14.8V 60C 4S1P XT60 LIPO Akkupack – Genspow GmbH

This is the BMS: EU Stock JK Bms Active Balance Bms 4S 8S 12S 16S 20S 24S Smart Bluetoo – SeLian Energy

How can I connect them? I want safe charge and discharge capabilty out of the Lipo. Also can I connect the cell cable directly to the BMS cell port?

Hi,

i'll start by saying i don't know a lot about I2C, i'm trying to use this encoder (with a custom pcb) as a drop in replacement for a mechanical pot (engine sensor), i need to use it only for a limited range (around 80°), and i need it to output (analog) around 0.4V and 4.3V between the 0 and 80°.

The problem is that i need to program it while it's mounted in place, and i can't move it to the angle where it should be at 0V or 5V (ZPOS and MPOS) because the rotation is limited mechanically, to rotate in the correct position where the ZPOS should be set, i'd need to remove it to do it on the bench but in that case is a pain to get the alignment right.

I'm sure if programmed without I2C you can only set ZPOS and MPOS or MANG, but with I2C is it possible to set ZPOS and MPOS with an offset? seeing their tutorial (https://www.youtube.com/watch?v=Dwc4hFgNP5I) maybe instead of  "raw angle -> ZPOS" you can do something like "raw angle-20° -> ZPOS"? idk because i don't know I2C.

The alternative would be to just program it in place with ZPOS and MPOS when mounted and the convert the 0-5V to 0.4-4.3V with an op amp.

I’ve been meaning to work on a Nucleo-N6 project that uses a TCP client.

I know this board is crazy complex so I was going to go through the CubeMX for configuration.

For some reason however I can’t build the NetXDuo TCP client example code and get the appropriate IOC file to configure the project through VsCode using ST’s extensions.

I was curious if anyone had experience with these issues or any alternatives to build for the N6 with CMake.

I started building a gameboy emulator last week as a SWE project to have on my resume, but I recently discovered my interest for embedded systems. Thinking of finishing my emulator then having it run on a micro controller with an LCD and real buttons. Would this be a good resume project or is it kinda cliche?

I’m designing a PCB that had a CM4 contained on the backplane, from which I’m in the process of doing some preliminary testing before I hand it off to someone else. I’m experiencing some weird behaviour which I haven’t experienced before whereby I power on the PCB with a CM4 set up for eMMC boot, and I’m not getting the expected power draw that indicates the CM4 is booting up properly (50mA approx for the CM4 itself). RPIBOOT is pulled high which is reflected on the oscilloscope at boot, RUN_PG is high also, and the Global enable is also high which is such by default. I’ve tried multiple pre configured CM4s, and they don’t work, and I’ve validated my power delivery from which is stable. If anyone has any idea, I’m all ears but I’m running out of them🥲

Hey everyone,

I wanted to share a capstone project I recently wrapped up and pushed to GitHub: a heterogeneous System-on-Chip (SoC) deployed on a Nexys A7 FPGA.

The main goal was to bridge high-level computer vision software (Python/OpenCV) with raw silicon using a custom hardware-software co-design.

Key Features of the Architecture:

• Custom RV32I Single-Cycle Core: Acts as the central firmware orchestrator, executing custom RISC-V assembly.
• Parallel MAC Accelerator: A custom 3x3 convolution block featuring 9 parallel multipliers and a log-depth adder tree to compute spatial derivatives (like Sobel-X) in a single cycle.
• Native CV_8U Hardware Clamping: Built-in combinatorial absolute value and saturation logic that matches OpenCV's clamping behavior (CV_8U) directly in silicon, avoiding two's complement wrap-around artifacts.
• MMIO Interconnect: Uses a 32-bit Memory-Mapped I/O bus to route data between Data RAM, the UART peripheral, and the accelerator.

The Hardest Engineering Hurdles & Fixes:

1. Setup Timing Violations: Early iterations used a linear accumulation chain for the 9 multipliers, which completely wrecked the critical path. I restructured the datapath into a log-depth parallel adder tree to resolve setup slack and hit a clean Setup WNS of 0.51 ns at 50 MHz.
2. UART Buffer Overruns / Smearing: Blasting 9-byte windows from Python over serial caused the FPGA receiver to drop bytes and scramble pixel arrays. Fixed it at the link layer by implementing a paced Big-Endian serial transmission protocol with rigid 2ms delays between bytes.

The repository includes the complete RTL (/rtl), host-side Python test/debug scripts (/sw), and a full architectural breakdown.

🔗 GitHub Repo: https://github.com/waseemnabi08/rv32i-vision-soc I'd love to hear your thoughts, feedback, or any questions about the microarchitecture or verification process!

So basically i am starting my bachelors in electrical engineering with electronics as a major and was planning to a project which will help me to proof my skills which i will in bachlors and through my self study and here is the summary of my project which i was plaining to do through out my whole bachlors degree

Here's your project summarized in one paragraph:

---

A wireless dual-mode controller and teleoperated ground vehicle system, built and evolved across four years of undergraduate study, designed to demonstrate core competencies relevant to mining automation technology. The controller functions as both a standard gaming input device and a mining vehicle operations console, featuring a custom-designed PCB, motion-based steering via IMU sensor fusion, and haptic feedback. The vehicle is a multi-processor system connected over CAN bus, equipped with environmental hazard sensors (gas, carbon monoxide, pressure, dust particulate), real-time drift/handling control via PID tuning, LoRa long-range wireless telemetry, TinyML-based predictive maintenance for motor health, and autonomous safety behaviors including automatic return-to-base on communication or power loss. The complete system integrates embedded C firmware, FreeRTOS real-time task management, Linux device drivers, Modbus and CAN industrial protocols, custom PCB design and fabrication, and machine learning deployed on constrained hardware — mirroring the core technical challenges of real-world teleoperated inspection vehicles used in mining and industrial environments.

So please guid me about it that is it a good project to do and worth giving a time and also i wana tell that i will do in phases like phase 1 2 3 and please guid that what should i do with it extra i am completely new to this field and just want have right guidance

I've been working on an open-source project called imud, which is essentially gpsd for IMUs.

The motivation was simple: every project that needs orientation data seems to end up writing another I²C driver, another calibration pipeline, another sensor fusion implementation, and another network protocol. If several applications want the same IMU, they either fight over the hardware or duplicate all of that work.

imud turns the IMU into a system service. It owns the sensor, performs the time-critical work once, and publishes fused attitude data that any number of applications can consume simultaneously.

Some implementation details:

• Written in C11 (libc + libgpiod)
• Interrupt-driven acquisition using the IMU FIFO instead of userspace polling
• Multiplicative Extended Kalman Filter (MEKF)
• Hardware timestamping
• Pluggable driver layer (reference hardware is ISM330DHCX + MMC5983MA)
• NMEA 0183, high-rate binary UDP, and AF_UNIX/TCP streaming interfaces
• Built-in capture/replay of raw sensor data for regression testing and filter development
• Calibration tools (gyro, accelerometer, magnetometer, Allan variance, gyro temperature characterization)
• World Magnetic Model support for true heading

The original motivation was marine navigation, but I've tried to keep the daemon general-purpose enough for robotics, machine vision, gimbals, or anything else that needs attitude estimation.

I'm particularly interested in feedback on the architecture. Does treating an IMU as shared system infrastructure (similar to gpsd for GNSS) seem like a useful abstraction, or would you rather see this functionality embedded directly into applications?

GitHub: https://github.com/richcreations/imud

First project I actually finished and I've been staring at my own code for too long, so I'd love some outside eyes on it.

It's Tetris on a NUCLEO-F446RE playing on 4 daisy-chained MAX7219 matrices, 8×32 playfield. Four buttons, score over UART. No HAL, no CMSIS device headers, no RTOS — I wrote the register definitions and the drivers myself from RM0390, mostly because I wanted to actually understand what the abstraction layers hide.

The bit I'm least sure about is how I structured the interrupts, so that's where I'd love feedback. I didn't want game logic running inside the button ISR, so I split it:

• EXTI ISR just debounces and drops a "move/rotate" intent into a variable, nothing else
• SysTick counts ms and pends PendSV every GAMESPEED ms
• PendSV runs at the lowest priority and that's where the whole game lives — eat the intents, gravity, collision check, clear rows, blit over SPI

Idea being that buttons and the tick never get blocked behind SPI or game logic. Kind of a bootleg RTOS scheduler made out of exception priorities. Intents are read-and-cleared with interrupts masked so a press can't get half-read. Is this reasonable or am I overthinking it? Would you have just done it in the main loop?

Pieces come out of a 7-bag (Fisher-Yates), seeded off SysTick at the first press so every game's different.

Full disclosure so nobody feels misled: I learned the GPIO/SPI drivers off Fastbit's MCU1 course, then extended them (table-driven RCC, SysTick/NVIC/SCB, CS helpers) and wrote the MAX7219 driver + the game myself.

Repo + a demo clip:https://github.com/ValeriiShypitko/TetrisProject

Honestly just tell me what's bad. Interrupt design, the driver APIs, the game code, naming, whatever — I'd rather hear it now than build the next three projects the same wrong way. Thanks for reading.

Edit: Problem was solved. It turned out that i was allocating 128KB RAM but the RAM of the board is not contiguous.

I'm hoping someone with more Cortex-M startup experience can point me in the right direction because I've run out of ideas.

I'm writing a fully bare-metal firmware for an STM32L476RG (no HAL, no CubeMX) using:

• arm-none-eabi-gcc 15.2.1
• CMake
• OpenOCD + GDB

The MCU boots, enters my Reset_Handler, and then immediately HardFaults before I ever reach main().

Background

A few weeks ago I completed a bare-metal bootloader for the same STM32L476RG board using almost the same startup code and linker script. That project worked correctly.

For this new robot project, the startup code is almost identical. The main changes are:

• Using the full 1024 KB FLASH and 128 KB RAM instead of the reduced FLASH and RAM layout I used previously.
• Explicitly reserving 4 KB heap and 4 KB stack in the linker script.
• Different application code (which I don't think matters because I never reach main()).

So this isn't my first startup implementation, which is why this has me so confused.

What happens

The processor reaches Reset_Handler correctly.

The first few instructions are:

push {r7, lr}
sub sp, #24
add r7, sp, #0

When stepping through with GDB:

• push {r7, lr} executes.
• Immediately afterwards execution ends up in HardFault_Handler.

I never reach the first ldr instruction.

I never reach the .data copy loop.

I never reach the .bss zeroing loop.

I never reach main().

Things I've already verified

I've spent quite a while checking the obvious things before posting.

Vector table

• Reset vector is correct.
• MSP is 0x20020000, which matches the top of 128 KB RAM.
• The vector table contents are correct.
• Flash alias at 0x00000000 matches the table at 0x08000000.

Linker

• FLASH origin and length are correct.
• RAM origin and length are correct.
• _sdata, _edata, _sidata, _sbss and _ebss all have sensible values.
• The literal pool in Reset_Handler contains exactly those addresses.

Startup code

• Reset_Handler is definitely entered.
• Flash contents match the generated ELF.
• The disassembly matches the actual bytes in flash.
• The startup code is just the normal .data copy, .bss clear and main() call.

Fault registers

At the HardFault:

HFSR = 0x40000000
CFSR = 0x1400

VTOR is 0x00000000 (Flash is aliased correctly).Fault registersAt the HardFault:HFSR = 0x40000000
CFSR = 0x1400VTOR is 0x00000000 (Flash is aliased correctly).

At this point I'm trying to understand what could cause a HardFault before even reaching the first ldr in Reset_Handler.

Am I overlooking something obvious in my startup code or linker script, or is there another direction I should be investigating?

I've uploaded the startup.c, linker.ld and CMakeLists.txt on the Github Gists link below:

https://gist.github.com/Lobstone7/b0e2303622e5b6d69f3eb64fd544118b

This is the newest iteration of a rather long-lived project that radically improves the usability and overall design quality: https://github.com/OpenCyphal-Garage/cy

It brings the bare minimum of decentralized pub/sub networking -- basic service discovery, gRPC-like streaming, and simple tunable QoS -- in a very compact design. One way to describe it is that it implements a few percent of the functionality offered by DDS that addresses a significant subset of its embedded applications. The main design goal is simplicity: features were removed until there was nothing left to remove; the transport-agnostic part fits into a single .c file and each transport (currently UDP and CAN) adds only a small adapter layer. It is really compact.

There is an equally simple Python implementation also: https://github.com/OpenCyphal/pycyphal

Both implementations come with usage examples, check them out!

We are currently working toward supporting TSN (formerly AVB) as a compatible extension of the existing UDP transport, such that one could operate it in a mixed network where some topics use TSN while others operate on conventional UDP.

Hi everyone,

Over the past few months I've been designing a tiny USB Type-A development board around the Raspberry Pi RP2354A, called Romu.

The goal wasn't to replace a Raspberry Pi Pico or similar boards, but to create something that could live on a keychain and be plugged directly into a computer whenever I wanted to quickly prototype firmware, experiment with USB, or test small ideas.

As you'd expect, fitting everything into a 15.5 × 12 mm PCB meant making a lot of design trade-offs.

For example, there simply isn't enough board area for dedicated SWD or UART connectors. Instead of making the board larger, I designed a separate pogo-pin fixture that provides access to USB, SWD, and UART whenever debugging or production programming is needed. The development board stays as compact as possible, while the jig provides access to everything during development.

The current feature set includes:

• RP2354A (2 MB flash)
• Native USB
• RGB LED
• Capacitive touch button
• Direct USB Type-A connection

I'd really appreciate any feedback. Thanks!

Can anyone suggest any books please, for guidance while learning embedded systems as a beginner??

I haven’t been using rp long, I got some rp2040 (like 10 I think) for a tomadachi auto drawer, and it was awesome I had a few things able to be made. However, I tried again a week ago, and today, with multiple different rp2040’s, and my none of them would recognize as a device on my pc. Any ideas of what’s wrong?

Hi,

I´m working with a custom carrier board for the CM4, and I can´t get my SSD to work. Now I´m wondering if my schematics are correct.

NOTE: The initial schematics have CLK-REQ and RST swapped. I fixed it with a small wire and then checked the connection with my Multimeter. It should be okay, but I´m not 100% sure. The ESD diodes aren´t assembled, and the PCIe lanes are length- and impedance-matched. I match the length of each trace in a group and the groups.

I enabled the SSD voltage on the CM4, plugged it in, and ran `lspci`, but the SSD isn´t listed. Did I miss something, or is the wiring wrong?

Thanks for the help!

Hello,

I am developing a system on the TMS570 platform and need to write diagnostic logs to an SD card. Initially, I was using the FatFs library, but I am required not to use an RTOS. Consequently, I planned to perform operations on the SD card at the raw block/sector level; however, this approach in my bare-metal setup still occupies and blocks the CPU.

I have several tasks requiring precise timing, so I cannot allow my simple scheduler to be blocked.

Is there a way to use the SD card without blocking the CPU?

Note: I am using DMA for SD card read/write operations.

Thanks best regards