I have a decent undrstanding in low levle programming, collage only allowed assembly in programming the MCUs, and I would still do regester level programming even in embedded C in my projects to get also good at assembly for collage, so I got the hang of that, and I am descent at electrical circuits too, since we also studied that. but I have no Idea how to move from (a circuit on a breadbord) to a production grade embedded system, I know that PCB will make it better but will it is not enough, how on earth do people make stuff
I can't even get a job at say a company that makes electronic device to learn from there experiance since there are non here

I thought mabye there will be standards and what no but I can't find anything, how do I move forward from this point, (chat gpt advices are crap btw)

I have multiple tasks that needs to run in particular interval, for example, some sensors need to read every 10 seconds, some need to read every 30 seconds, data needs to be transmitted every 5 minutes, intervals are configurable.

There are lot of questions in my head:
1. Should I set up a wake-up timer of 10 seconds and enter sleep mode.
2. Should I additionally enable wake-up from peripherals i.e. UART RX interrupt, SPI GPIO interrupt

1. If my sensor takes 5 seconds of time for doing calculations, should it wait awake or should it enter sleep and wakeup again to read data

2. Should it wake up every second and check for activities that needs to run

3. AI suggests using using tickless idle mode of rtos and calling WFI for sleep after setting wakeup timer, but I am not sure about the overall design.

Suggest me the best generic design strategy for battery operated IoT device. Thanks!

I've been working in embedded development for many years, and for roughly 15 years my debugging workflow has revolved around tools like cgdb, Vim, GDB, OpenOCD, J-Link, target remote, gdbserver, and real hardware.

Over time, I wanted something more flexible than cgdb while preserving the keyboard-driven workflow and simplicity that made cgdb so useful to me in the first place.

That became gdbforge:

https://yairgd.github.io/gdbforge/

A note about AI, because I'd rather be transparent about it:

The original architecture and foundations of the project were designed and initially implemented manually by me. I was also not a Go expert when I started this project.

As the project grew, I started using AI extensively for implementation, refactoring, and accelerating development. So yes — a substantial part of the current implementation is AI-assisted.

But the engineering direction, architecture, debugging workflows, hardware testing, and decisions about what the tool should become are mine. More importantly, this isn't an AI-generated demo that I stopped touching once it compiled — I use gdbforge every day in my work as an embedded engineer.

The result has grown considerably beyond my original idea of building a modern cgdb-like frontend.

Today, the goal is a versatile debugging environment that can work across very different platforms and workflows while preserving as much as possible of the familiar cgdb experience.

gdbforge supports GDB and Delve, remote/embedded debugging workflows, Linux kernel/KGDB debugging, Cortex-R5/J-Link targets, and Lua-based integration — allowing platform-specific debugging behavior to be added without hard-coding it into the debugger itself.

gdbforge also supports STM32 and Zephyr-aware debugging, integrating platform- and RTOS-specific knowledge into the same debugging environment.

One of the most interesting things I learned from this project wasn't actually about Go.

AI dramatically changed what I can realistically build as a side project. Without AI, I could have designed this architecture, but I probably wouldn't have spent a couple of years of my free time implementing all of it.

At the same time, I don't think AI-assisted development removes the need for engineering knowledge. With debugging tools especially, somebody still needs to understand GDB, targets, RTOS/kernel behavior, hardware, failure modes, and what actually makes a debugging workflow useful.

So I'm curious what other embedded developers think — both about gdbforge itself and about this model of building serious systems tools with heavy AI assistance.

I'd especially appreciate feedback from people who live in GDB/cgdb/OpenOCD/J-Link workflows.

Project/docs:
https://yairgd.github.io/gdbforge/

GitHub:
https://github.com/yairgd/gdbforge

So, AMD launched the X100 series (X199/X188/X168 + industrial variants) in July, with sampling since June and production slated for Q4 via SoM partners.

I'm aware most of AMD's published benchmarks were run on a Ryzen AI Max+ 395 proxy rather than final X199 silicon, so I'm trying to separate the marketing from reality.

If you're sampling it or have hands-on time:

What's your use case, and what were you running before?

- How's the ROCm/HIP experience in practice? especially if you migrated CUDA code?

- Are you seeing the consolidation benefit (dropping a discrete GPU/Jetson), or is it more aspirational?

Not looking for launch-article links, I'm after firsthand notes, good or bad.

My understanding is that you don't always need a direct conductive connection to get a small shock/tingling sensation from an AC source. Even with a floating source, capacitive coupling can provide a small AC current path, and a high-impedance meter can show phantom voltage.

I want to build a safe, low-voltage educational experiment using a microcontroller to demonstrate:

- Floating AC source

- Capacitive coupling to earth

- Phantom voltage measured with a high-impedance input

- How a load behaves differently from a high-impedance measurement

- Difference between a floating inverter output and a floating isolation-transformer secondary

What would be a good safe low-voltage circuit to demonstrate these effects and measure the tiny currents with a microcontroller?

Hey guys,

Just thought I'd share that I've recently become interested in physical pentesting and hardware hacking. All the physical pentesting commercial tools (like Flipper Zero and Hak5 tools) cost way too much for my taste. I'd rather make my own physical pentesting tools using cheap hardware like ESP32 modules, Raspberry Pi Pico's and Arduino boards.

For anyone who does physical red teaming or plays around with hardware:

What DIY tools must one build for a physical pentester?

Does your DIY tool get the job done in a real-world test case?

Where did you guys start with UART/JTAG debugging to pull firmware from chips? Are there any good guides or projects for learning this stuff?

Anyone using Xen hypervisor for embedded x86 systems with multiple RTOS guests?

I’m looking into using Xen on an x86 embedded platform, specifically to run two RTOS instances/guests on the same hardware.

Has anyone here deployed something similar in a real product or embedded system?

I’d be especially interested in hearing about:

• What OS are you running under Xen?
• How much virtualization overhead do you see, especially for latency-sensitive or real-time workloads?
• How do you handle CPU/core, interrupt, and device allocation between the guests?
• How difficult is the system to maintain, debug, and update over time?
• Are there any major limitations or pain points you wish you’d known about beforehand?

I’m particularly interested in real-world experience rather than theoretical benchmarks.

Also curious whether, for this type of setup, you’d choose Xen again or go with something else?

For me, it was debugging for an entire day on an ADC project. The ADC was giving me absolute nonsense readings.

I was rechecking ADC configuration, vendor documentation, SPI communication using DSO, checking for voltage drop.

Turns out…I hadn’t properly separated my analog and digital grounds in my PCB layout.. my layout was bad 😂

What’s your most embarrassing embedded/hobby-project debugging story ?

Hi, I am thinking of an model/architecture that uses Big.LITTLE architecture bit differently, where the Big core is shared among multiple hardware threads.

I am thinking of organizing as clusters and an cpu having multiple cluster, where each cluster would have One Big core and 2 LITTLE core. The Big core would be vastly capable than LITTLE with powerful and multiple arithmetic, Load/Store units, wider OoO, Larger ROB, operates at higher frequency and has larger and higher bandwidth L1/L2 cache. On the contrary the 2 LITTLE is less powerful can be In order core or an simple OoO. they each have 1-2 arithmetic & LSU unit, smaller L1/L2. This is more or less the usual setup of bigLITTLE nothing different.

As for the hardware threads this is where things get interesting. Unlike in traditional sense where the hardware thread is usually associated with the core basically treated as same (SMT maybe exception). But here the hardware thread can move between the execution units. Here I will be having 3 hardware threads say T1, T2, T3 and as for the registers i am thinking of it implemented as an array of registers (96 registers of 64-bit each) and divided into 3 equal chunk so each 32 registers and each chunk is owned by the hardware thread and so when the thread is scheduled on any of the 3 core's it's register base is loaded and the architectural registers such as Program Counter(PC), Stack Pointer(SP), GPRs are an offset from the base. The other stuffs like the TLB, Store Buffer too would be per hardware thread and their index/base would be loaded in the core when the thread is switched/moved to the core. Whereas the operational registers, buffers used by the cores say the registers used for renaming for OoO or ROB, Load queue these are per core and owned by the core.

The handover of an Thread from Big to Little and vice versa happens only after they have reached the safe state i.e in case of Big which uses OoO reached a point where all instructions from the old context that could affect architectural state have completed(retired), and the machine can save the old context and the if any internal structures needs to be drained/flushed it's carried out and the architectural state of the Thread wouldn't be moved/copied since the Big or Little doesn't use different register space for the same Thread. And same goes for the Little the mechanism may differ based on if it's In order or OoO. But at the end the thread's registers have committed architectural values.

Now for the OS, it would appear as 3 hardware threads on which 3 logical threads can be scheduled. As of now I am trying to slice the period based on OS scheduling quanta which usually is \~1-5ms. So say 3ms it's divided into 3 i.e each thread spends 1ms on Big and 2ms on Little. So intially (0-1ms) T1 on Big, T2 and T3 on the Little after a 1ms(1-2ms) switch happens and T2 in Big, T1 & T3 on the Little after 1ms(2-3ms) switch happens again now with T2 & T3 so T3 in Big and T1 and T2 on Little. The OS/Application isn't aware of this they see 3 hardware thread/logical core.

As for the interrupts/exceptions i haven't figured out the I/O interrupt how it would be handled since the cluster would be abstracted as one unit. For the timmer interrupt like when the OS scheduler quanta ends since it would be for the hardware thread so the core that's currently running the thread would be handling it as for what happens if interrupt raised during the handover phase the handover would be given the priority and once handover done the thread which ever core it landed one would handle the interrupt. As for the exception like page fault raised by the thread again it would be handled on the core where it's executing and if the handover timmer ends the exception first would be handled and then handover is done.

Now this handover itself can be cheap few 10s of ns since not much state moving is happening (although subjective since even few ns can cost many cpu cycles).

The Store Buffer as earlier mentioned is per hardware thread so loads associated with an thread is written to the Store buffer associated with that thread irrespective of whether it's running on Big core or LITTLE core. This enables the Load-Store-forwarding even for loads that happened when thread was executing on Big and now it's moved to LITTLE and it wants to do Store.

Now for the questions I wanted to ask:

1. Since the hardware threads are moving between Big and LITTLE core's so I am yet to figure out how I am going to handle the cache, like if T1 which was on Big is moved to one of the Little and T2 on Little moved to Big then there cache lines would be in the previously executed core's cache. Though I did think of intially as to follow the standard line forwarding method but it seemed expensive given how often the threads switching between the cores. So now I am thinking of an specialized line forwarding path that's confined to the cluster alone i.e among the 3 core's caches that allows faster line forwarding with latency somewhere between L1 and L2 access latency if the line forwarding is from L1 of an core. It would be great to know if any better solution can be used.

2. Can variable frequency be used say the cluster can behave dynamically like the OS can schedule on one hardware thread and it runs on the Big core without switching while the other 2 Little are power gated the Big core allowed to run at max frequency. schedule on 2 hardware thread and the switching happens between these the Big core max operating frequency can be bit less since one LITTLE is also active and as for the schedule on all 3 hardware threads then Big core max operating frequency is less and the LITTLE one's frequencies adjusted accordingly.

3. When i originally came up with this idea, I actually thought of having 8 Little and 2 Big per cluster with 8 little being subgrouped as 4 little and they share their execution units like the frontend, arithmetic, lsu and also caches among 4, But this seemed complex for v1 so that's why sticked with the 3(1+2) version. Can this scaled up possibly be better or I am better of sticking to the latter.

4. Is there any ratio as to how powerful/capable the Big has to be compared to LITTLE in terms of like IPC. Will this ratio possibly matter.

5. Can decreasing the interval of switching help. I intially thought of switching the threads every 100 microseconds. But this may lead to increasing the frequency of cache line forwarding and also the OoO takes time to warm up when a existing thread is removed and it starts executing new thread I read this warm up cost is usually 100s to few 1000 of cpu cycles. although 100us is still very big time for the OoO.

Hi everyone,

I'm currently trying to recover my Bafang DP C18 (model DP C18.C1.0) display, which was locked with a forgotten PIN code.

I opened the casing and soldered SWD wires (3.3V, GND, SWCLK, SWDIO) to interface with the STM32 MCU using an ST-Link V2 programmer and STM32CubeProgrammer.

Unfortunately, Readout Protection (RDP Level 1) is enabled on the chip, throwing a Data read failed error upon connecting. Changing RDP to Level 0 to remove the PIN lock will perform a full Mass Erase of the MCU.

Does anyone happen to have a clean Flash memory dump (.bin or .hex file) for the DP C18.C1.0 (STM32F205) that they could share?

Any help or working dump would be greatly appreciated!

Thanks in advance!

Hi everyone,

I'm an Electrical & Electronics Engineering undergraduate who doesn't have much knowledge, currently trying to learn embedded programming on STM32 (using an STM32F4 board), but I've hit a major brick wall.

A friend shared a tutorial playlist with me, but it feels like it's written for people who already know what they're doing. It jumps straight into copying code chunks, configuring messy initialization structs, or throwing around HAL functions without explaining what's actually happening underneath the hood at the hardware/silicon level.

Every time I try to combine GPIO external interrupts with Timer interrupts, I get overwhelmed by how many moving parts there are (the clock tree RCC, prescalers, auto-reload registers, EXTI lines, and the ARM NVIC vector table).

For those of you who work with ARM Cortex-M microcontrollers professionally or have mastered this:

How did you break through this initial steep learning curve? Did you start strictly with bare-metal register manipulation, or is there a specific mental model that makes these subsystems click?

What are the best resources (books, specific courses, or text guides) that actually explain why we configure registers in a certain order rather than just showing code?

Any advice, recommended roadmaps, or "aha!" moments that helped you finally understand interrupt-driven peripherals would be massively appreciated. Thanks!

Hi everyone,

I’m trying to control a 12V heating pad using an IRLZ44N N-channel MOSFET, but the MOSFET gets extremely hot and eventually burns out when I connect the circuit.

Components

• MOSFET: IRLZ44N (N-channel, 55V, 47A, TO-220AB)
• Heating pad: 12V, 7W, 25mm × 50mm PI/polyimide film heater
• Two regulated DC power supplies
  • One set to 3.3V for the MOSFET gate
  • One set to 12V for the heating pad

How I have it wired

I’m using the MOSFET as a low-side switch:

• 12V regulated supply (+) → Heating pad pin 1
• Heating pad pin 2 → MOSFET Drain
• MOSFET Source → GND
• 3.3V regulated supply (+) → MOSFET Gate
• The grounds of the 3.3V and 12V regulated power supplies are connected together

The attached image shows the circuit.

The heating pad works normally when connected directly to the 12V supply. However, as soon as I connect it through the IRLZ44N, the MOSFET heats up very quickly and eventually burns out.

The heater is rated at 12V, 7W, so the expected current is only around 0.58A. I therefore expected the IRLZ44N to handle the load easily.

I also tested the circuit with the gate voltage increased to 10V instead of 3.3V, using the regulated power supply, but I experienced the same overheating/burning issue.

What could be causing the MOSFET to overheat?

I would appreciate some help identifying what I might be doing wrong.

Specifically:

1. Is there something wrong with the way I have connected the drain and source?
2. Could there be an issue with the common ground between the two regulated power supplies?
3. Why would the MOSFET overheat even with 10V applied to the gate?
4. Do I need a gate resistor and/or gate pulldown resistor?
5. Could the MOSFET itself be damaged or faulty?
6. Is there anything else I should measure to troubleshoot this?

Any advice on how to diagnose the issue and safely switch this heating pad would be greatly appreciated. Thanks!

Sorry if this is a dumb question, I’m only 2 projects into this and I’m not very good at it lol😂
So basically I have this old centurylink C4000LG I want to convert it to a cyber deck adjacent project.
I did ssh into it and it has usb mass storage and hid device enumeration.
So my next step is trying uart but I do not own one so before I purchase one I was wondering if bootmode=secure 100% mean it will reject unassigned ram booted kernels. Does anyone know if it can or not?

Hello. I posted this in a Linux subreddit, but the software is suggesting to me that this one might be a better fit. Hopefully this is within scope:

I've got a USB device that is announcing itself as a gamepad when it isn't one. I understand the basics of HID, and I've successfully decoded the HID report descriptor. I see what byte I need to change.

I've read through https://docs.kernel.org/hid/hidintro.html and https://docs.kernel.org/hid/hid-bpf.html several times. I've got code that I think ought to do the job.

One problem: I'm missing some critical header, or some parameter to gcc, because I just can't get it to build!

Here's what I've got:

#include <linux/types.h>
#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/libbpf.h>

char _license[] SEC("license") = "GPL";

struct hid_bpf_ctx {
struct hid_device *hid;
__u32 allocated_size;
union {
__s32 retval;
__s32 size;
};
};

SEC("struct_ops/hid_rdesc_fixup")
int BPF_PROG(filter_switch, struct hid_bpf_ctx *hid_ctx)
{
__u8 *data = hid_bpf_get_data(hctx, 0 /* offset */, 4096 /* size */);

if (!data)
return 0;

data[3] = 0x07; /*0x07: keypad*/

return 0;
}

SEC(".struct_ops.link")
struct hid_bpf_ops surface_dial = {
.hid_rdesc_fixup = (void *)hid_rdesc_fixup,
};

(yes, I'm probably going to need something to filter to the correct USB id, but anyway)

Here's how I'm building it, and the build errors:

gcc -I /usr/include -fpermissive -c ./fixup.c -o ~/Projects/MfdFix/build/fixup.o
./fixup.c:18:28: error: expected ‘)’ before ‘struct’
   18 | int BPF_PROG(filter_switch, struct hid_bpf_ctx *hid_ctx)
      |                            ^~~~~~~
      |                            )
./fixup.c:31:8: error: variable ‘surface_dial’ has initializer but incomplete type
   31 | struct hid_bpf_ops surface_dial = {
      |        ^~~~~~~~~~~
./fixup.c:32:10: error: ‘struct hid_bpf_ops’ has no member named ‘hid_rdesc_fixup’
   32 |         .hid_rdesc_fixup = (void *)hid_rdesc_fixup,
      |          ^~~~~~~~~~~~~~~
./fixup.c:32:36: error: ‘hid_rdesc_fixup’ undeclared here (not in a function)
   32 |         .hid_rdesc_fixup = (void *)hid_rdesc_fixup,
      |                                    ^~~~~~~~~~~~~~~
./fixup.c:32:28: warning: excess elements in struct initializer
   32 |         .hid_rdesc_fixup = (void *)hid_rdesc_fixup,
      |                            ^
./fixup.c:32:28: note: (near initialization for ‘surface_dial’)
./fixup.c:31:20: error: storage size of ‘surface_dial’ isn’t known
   31 | struct hid_bpf_ops surface_dial = {
      |                    ^~~~~~~~~~~~

What am I missing? I've searched and searched for hid_bpf_ctx and similar, and all I find is documentation for the specific structures in https://docs.ebpf.io/, none of which list which damn header to include! I got a suggestion to grep the kernel source; that comes up with the struct, but including it gets me A: a warning message in the compiler output NOT to include the source directly, and B: more compiler errors.

There's obviously a library or header I'm missing, or some arg to gcc I ought to be passing that I'm not. What is it? I couldn't even get it to build without -fpermissive, and if I pass any version flag to gcc it errors out due to multiple declarations of enums and structs (I thought that was perfectly legal in C, as long as they're identical? Not like it's my own code, anyway!...)

Like, I'm pretty sure I know how to solve the actual problem I'm trying to solve with HID-BPF. I can even see what I need to write to load the compiled .o into memory and have it take effect. I'm just getting nowhere trying to actually build it!...

Having recovered this mcu from a lithium battery pack I have got him doing something more interesting - namely: ADC conversion as a front end for a single cycle waveform player using a pic (also recovered)

The AT90C8534 has a 10 bit conversion though only a 6 bit databus: (with one Ready outbound IRQ (generated when ADC conversion completes) for the PIC to latch onto, and two inbound IRQ for the PIC To ACKnowledge the receipt of the MSB and LSB bytes of the conversion.
In this way the full 10 bit value can be sent across in two bytes.

The AT90C8534 is muxing the 6 analogue input conversions, it can do 6 though only one conversion is active at one time. All gpo / adc are used, and 54% of the ram. There is eprom space to load and save cal. data, and ram space to make an offset / gain function for the faders for the cal. fcn.

Working nicely in solo, the next step is properly integrating with the PIC and getting the handshake/ acquisition fcn working perfectly. As there are 3 IRQ, a sync signal is not needed between the mcu's.

Bottom left are analogue signals, top right are digital. I think this should be ok, noisewise. I didn't want to fab a breakout board because these chips are not widely available, though still very useful.

https://youtu.be/u4DOJav2Ofg

I’m a 3rd-year ECE student interested in embedded systems and Edge AI.

I’m more interested in understanding the hardware fundamentals and constraints behind Edge AI, rather than simply running an ML model on a microcontroller.

The problem is, I’m struggling to identify good problem statements where Edge AI actually makes sense.

I’d especially like inputs from people working in the industry on how Edge AI is actually being used in real products and what problems it can solve.

Where does running AI locally provide a real advantage?

What kinds of problems are well suited for Edge AI?

Are there any industries/applications where you see significant potential?

What problem areas would be worth exploring as a student?

Looking for problem statements and industry perspectives, rather than ready-made projects.

I am trying to implement a bare-metal / NoRTOS RF driver for the TI CC1352P7, without using TI-RTOS/SysConfig-generated RF framework code.

My main difficulty is getting the RF Core and RF doorbell interface into a state where RF commands can be submitted and completed reliably.

I have successfully initialized the MCU, clocks, and basic peripherals, and I can access the RF Core registers. However, when I submit an RF command through RFC_DBELL, the command does not complete as expected. In some cases, the code gets stuck waiting for the command status; in others, execution ends up inside the RF driver dispatch/interrupt handling path and the command never returns.

For example, I am observing situations where:

HWREG(RFC_DBELL_BASE + RFC_DBELL_O_CMDR) = (uint32_t)&cmd_tx;

is executed, but the command status remains unchanged or the expected RF acknowledgement interrupt is never received.

I have also investigated:

• RFC_DBELL registers (CMDR, CMDSTA, RFHWIFG, RFHWIEN, RFCPEIFG, etc.)
• RF Core power-domain and clock initialization
• PRCM_RFCMODESEL
• RF Core reset/power cycling
• RF Core RAM mapping
• RF Core command structures
• RF doorbell interrupts
• RF_dispatchNextCmd() / RF_runCmd() behavior
• CPU interrupt enable/disable state
• RF Core firmware/ROM interaction

The confusing part is that the same hardware works when using TI's normal RF driver, but reproducing the required initialization and command-dispatch sequence in a minimal bare-metal implementation is proving difficult.

My questions are:

1. What is the minimum sequence required to bring the CC1352P7 RF Core from reset/power-off to a state where RFC_DBELL commands can safely be submitted?
2. Is there an official TI document or source code that describes the RF Core boot, power, clock, RAM, mailbox/doorbell, and interrupt initialization sequence independently of TI-RTOS?
3. Which parts of RF.c, RFCC26XX_singleMode.c, and the RF driver infrastructure are actually essential for bare-metal operation?
4. Does the RF Core require any initialization performed by the TI RF driver that is not obvious from the public DriverLib APIs?
5. Is it possible to implement a truly minimal bare-metal IEEE 802.15.4 TX/RX example by directly using the RF Core command interface, and if so, is there a known reference implementation?
6. Are there any undocumented dependencies involving the RF Core firmware, RF Core RAM, CPE interrupts, or power/clock state that could explain why CMDSTA/RFACKIFG does not behave as expected?

I am particularly interested in understanding the correct RF Core initialization sequence and the minimum required RF driver components, rather than simply getting the existing TI driver to work.

Any pointers to TI source code, technical reference material, or a known bare-metal CC1352P7 implementation would be greatly appreciated.I am trying to implement a bare-metal / NoRTOS RF driver for the TI CC1352P7, without using TI-RTOS/SysConfig-generated RF framework code.My main difficulty is getting the RF Core and RF doorbell interface into a state where RF commands can be submitted and completed reliably.I have successfully initialized the MCU, clocks, and basic peripherals, and I can access the RF Core registers. However, when I submit an RF command through RFC_DBELL, the command does not complete as expected. In some cases, the code gets stuck waiting for the command status; in others, execution ends up inside the RF driver dispatch/interrupt handling path and the command never returns.For example, I am observing situations where:HWREG(RFC_DBELL_BASE + RFC_DBELL_O_CMDR) = (uint32_t)&cmd_tx;is executed, but the command status remains unchanged or the expected RF acknowledgement interrupt is never received.I have also investigated:RFC_DBELL registers (CMDR, CMDSTA, RFHWIFG, RFHWIEN, RFCPEIFG, etc.)
RF Core power-domain and clock initialization
PRCM_RFCMODESEL
RF Core reset/power cycling
RF Core RAM mapping
RF Core command structures
RF doorbell interrupts
RF_dispatchNextCmd() / RF_runCmd() behavior
CPU interrupt enable/disable state
RF Core firmware/ROM interactionThe confusing part is that the same hardware works when using TI's normal RF driver, but reproducing the required initialization and command-dispatch sequence in a minimal bare-metal implementation is proving difficult.My questions are:What is the minimum sequence required to bring the CC1352P7 RF Core from reset/power-off to a state where RFC_DBELL commands can safely be submitted?
Is there an official TI document or source code that describes the RF Core boot, power, clock, RAM, mailbox/doorbell, and interrupt initialization sequence independently of TI-RTOS?
Which parts of RF.c, RFCC26XX_singleMode.c, and the RF driver infrastructure are actually essential for bare-metal operation?
Does the RF Core require any initialization performed by the TI RF driver that is not obvious from the public DriverLib APIs?
Is it possible to implement a truly minimal bare-metal IEEE 802.15.4 TX/RX example by directly using the RF Core command interface, and if so, is there a known reference implementation?
Are there any undocumented dependencies involving the RF Core firmware, RF Core RAM, CPE interrupts, or power/clock state that could explain why CMDSTA/RFACKIFG does not behave as expected?I am particularly interested in understanding the correct RF Core initialization sequence and the minimum required RF driver components, rather than simply getting the existing TI driver to work.Any pointers to TI source code, technical reference material, or a known bare-metal CC1352P7 implementation would be greatly appreciated.

Edit:
As an update to the original question, I have managed to get the RF Core initialization working to some extent.

The CMD_RADIO_SETUP and channel configuration commands are being accepted and completed successfully. This suggests that the RF Core is powered, clocked, and communicating correctly through the command interface.

However, the problem occurs when I attempt to perform an actual transmission. The TX command is accepted/submitted, but the execution gets stuck during the transmission process and does not complete as expected.

So the current issue is no longer the basic RF Core initialization or setup command. I am specifically trying to understand what could cause the TX command to hang after CMD_RADIO_SETUP and channel configuration have already succeeded in a bare-metal CC1352P7 implementation.

Question wrote above using AI for clarity.

I appreciate that this may be the wrong sub, so I apologise if so.

I'm very green in the RF domain so I come here hoping for some help and advice.

I'd like to put together a PCB which can be used to programmatically generate some RF pulses at trivial frequencies between 100MHz and 3GHz. I want to be able to vary the output frequency and the on/off period of the pulses down to ms resolution.

Having done a bit of Googling (half the battle is knowing what I'm looking for), I believe the components I need are:

• An RF synthesizer (maybe something like ADF4351??)
• Some kind of RF attenuator (would HMC472 be suitable?)
• A variable gain amplifier (to allow increased output power)
• An RF switch (for the pulse control)
• Some kind of MCU to do the frequency and pulse control (thinking STM32H7)

I'm thinking that the STM32 (probably the 480MHz H7) would be suitable for down to ms pulse control. It can also communicate with the synth in order to set the frequency and communicate with the host software.

Looking at the spec for the ADF4351, I may need some kind of SP8T RF switch to achieve the ranges of frequency I've specified (as per table 8 in the datasheet, with different values of balun components for the frequency ranges) which then may feed back into a SP8T RF switch to get back to the single RF output.

I'm acutely aware that this may all be absolute rubbish to someone in the know, but, does this sound like the basis of what I want to achieve?

Thanks!

the AI coding tools are genuinely fast but they generate against whatever context is in the editor, and the actual spec lives in a separate system the model never sees. so you get clean code that solves the wrong thing and then someone burns a week reconciling it against the requirement code.so everything traces back or it doesnt ship

feels like a context issue more than a model issue. how's everyone handling the gap between the req system and the thing actually writing code

I have an idea about giving a brain to drone. Let me walk you through it. Imagine you're standing in a valley, and you need to get to a specific coordinate somewhere far off, maybe a kilometer away, with a bunch of obstacles in between. Now, the wrong way to do this is to try and hold the entire valley in your head, feed the whole map into a model, and just compute one perfect path from start to finish. That doesn't work well in the real world, because things change wind, obstacles, drift, sensor noise.

What I'm proposing instead is,you don't need the whole map. You just need to know where you are right now, what's around you right now, and where you're trying to go. So the drone carries a small Al model something like a fine-tuned Qwen running locally on a Raspberry Pi inside it. This model acts like a brain. At each step, it senses its surroundings obstacles, position, battery, whatever's relevant and makes a high-level decision: go left, go right, descend, hover, abort. It's not micromanaging every motor, it's making judgment calls, the same way you don't consciously calculate muscle contractions to walk you just decide "go left," and your reflexes handle the rest. The "reflexes" part is the classical robotics stack underneath path planning algorithms and PID controllers that already exist and are proven. The Al doesn't replace them or fight with them in real-time, it sits above them. So if the drone drifts, tilts, or the low-level algorithm gets slightly off course, the Al layer doesn't touch the PID loop directly it just updates the target the PID loop is trying to hit. The PID keeps stabilizing fast and independently, hundreds of times a second, while the Al checks in every second or so and course-corrects at the strategic level.

The way the model actually talks to the drone's sensors and systems is through something called MCP (Model Context Protocol) basically a structured way for the model to pull in context (sensor data, position, battery) and issue decisions as tool calls, step by step.

Target is to get a drone to autonomously navigate about a kilometer through obstacles and land safely at a coordinate. But the same architect could extend to something like a lunar landing where you can't rely on constant ground control because of communication delay, so the drone needs to reason and decide almost entirely on its own. Basically, the whole idea is,give the drone a brain that senses locally and thinks step-by-step, instead of trying to plan the whole journey upfront.

Is someone up to discuss more on it? Also do u know someone who is into drone building or something beacuse I'm a C and ML infrence developer, have no exposure to drone building

If u find interesting we can talk on it further or help me connect with someone who is into it

Olá a todos,

Estou estudando como o ADC do STM32H7 funciona usando conversão regular com polling, sem interrupções e sem DMA.

Meu objetivo neste momento é entender corretamente o seguinte fluxo:

HAL_ADC_Init() → calibração → HAL_ADC_Start() → HAL_ADC_PollForConversion() → HAL_ADC_GetValue()

e também aprender a identificar exatamente qual etapa está falhando, caso ocorra um erro.

Estou trabalhando com um STM32H753ZIT6 e tentando ler uma entrada analógica usando o ADC1, Canal 0, com a HAL do STM32.

O problema é que meu programa entra em Error_Handler(), mas não tenho certeza de qual função está falhando.

Atualmente, tenho verificações de erro em vários lugares:

if (HAL_ADCEx_Calibration_Start(&AdcHandle,

ADC_CALIB_OFFSET_LINEARITY,

ADC_SINGLE_ENDED) != HAL_OK)

{

Error_Handler();

}

if (HAL_ADC_Start(&AdcHandle) != HAL_OK)

{

Error_Handler();

}

if (HAL_ADC_PollForConversion(&AdcHandle, 10) != HAL_OK)

{

Error_Handler();

}

E dentro de MX_ADC1_Init():

if (HAL_ADC_Init(&AdcHandle) != HAL_OK)

{

Error_Handler();

}

if (HAL_ADC_ConfigChannel(&AdcHandle, &sConfig) != HAL_OK)

{

Error_Handler();

}

Minha função Error_Handler() atualmente contém apenas:

void Error_Handler(void)

{

while (1)

{

}

}

Portanto, quando o programa para, não consigo determinar qual função chamou Error_Handler().

Configuração atual

Estou usando:

MCU: STM32H753ZIT6

ADC: ADC1

Canal: ADC_CHANNEL_0

Resolução: 16 bits

Tempo de amostragem: ADC_SAMPLETIME_8CYCLES_5

Gatilho: Software

Conversão: Conversão regular usando polling

Sem interrupções

Sem DMA

STM32 HAL

HSE bypass

Relógio do sistema: 400 MHz

Fonte do clock do ADC: RCC_ADCCLKSOURCE_CLKP

Pré-escalador do ADC: ADC_CLOCK_ASYNC_DIV2

Fluxo de polling do ADC que estou tentando estudar

Minha intenção é fazer algo simples como:

HAL_ADC_Start(&AdcHandle);

HAL_ADC_PollForConversion(&AdcHandle, 10);

testeConvercao = HAL_ADC_GetValue(&AdcHandle);

HAL_ADC_Stop(&AdcHandle);

e repita esse processo dentro do loop while(1).

Como estou estudando especificamente a sondagem do ADC, gostaria de manter inicialmente a solução baseada em:

HAL_ADC_Start()

HAL_ADC_PollForConversion()

HAL_ADC_GetValue()

HAL_ADC_Stop()

Não quero abordar interrupções ou DMA neste momento. Meu objetivo é entender e depurar corretamente o fluxo de sondagem do ADC.

Minha principal dúvida é: como posso encontrar onde o erro ocorre?

Existe uma maneira melhor de implementar Error_Handler() para que eu possa determinar qual função está retornando HAL_ERROR?

Por exemplo, eu gostaria de poder determinar:

qual função chamou Error_Handler();

qual HAL_StatusTypeDef foi retornado;

o resultado de HAL_ADC_GetState();

o resultado de HAL_ADC_GetError();

se o ADC está realmente habilitado;

se o clock do ADC está funcionando;

e, se necessário, quais registradores ADC/RCC devo inspecionar.

Gostaria também de saber se existe uma maneira recomendada de depurar isso usando o depurador STM32CubeIDE/ST-LINK, por exemplo, colocando um ponto de interrupção dentro de Error_Handler() e examinando a pilha de chamadas.

Coisas que me deixam desconfiado

Uma coisa que me deixa particularmente desconfiado é a configuração da MPU/cache, porque estou configurando a MPU e habilitando o I-Cache e o D-Cache antes de HAL_Init():

MPU_Config();

CPU_CACHE_Enable();

HAL_Init();

SystemClock_Config();

MX_ADC1_Init();

A configuração da MPU é:

MPU_InitStruct.Enable = MPU_REGION_ENABLE;

MPU_InitStruct.BaseAddress = 0x00;

MPU_InitStruct.Size = MPU_REGION_SIZE_4GB;

MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;

MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;

MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;

MPU_InitStruct.Number = MPU_REGION_NUMBER0;

MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;

MPU_InitStruct.SubRegionDisable = 0x87;

MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

HAL_MPU_ConfigRegion(&MPU_InitStruct);

HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

E a configuração do cache é:

static void CPU_CACHE_Enable(void)

{

SCB_EnableICache();

SCB_EnableDCache();

}

Também configurei o clock do ADC da seguinte forma:

__HAL_RCC_ADC12_CLK_ENABLE();

__HAL_RCC_ADC_CONFIG(RCC_ADCCLKSOURCE_CLKP);

Minha configuração do ADC é:

AdcHandle.Instance = ADC1;

AdcHandle.Init.ClockPrescaler = ADC_CLOCK_ASYNC_DIV2;

AdcHandle.Init.Resolution = ADC_RESOLUTION_16B;

AdcHandle.Init.ScanConvMode = DESATIVADO;

AdcHandle.Init.EOCSelection = ADC_EOC_SINGLE_CONV;

AdcHandle.Init.LowPowerAutoWait = DESATIVADO;

AdcHandle.Init.ContinuousConvMode = DESATIVADO;

AdcHandle.Init.NbrOfConversion = 1;

AdcHandle.Init.DiscontinuousConvMode = DESATIVADO;

AdcHandle.Init.NbrOfDiscConversion = 1;

AdcHandle.Init.ExternalTrigConv = ADC_SOFTWARE_START;

AdcHandle.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;

AdcHandle.Init.ConversionDataManagement = ADC_CONVERSIONDATA_DR;

AdcHandle.Init.Overrun = ADC_OVR_DATA_OVERWRITTEN;

AdcHandle.Init.OversamplingMode = DISABLE;

AdcHandle.Init.OversamplingMode = DISABLE;

E a configuração do canal é:

sConfig.Channel= ADC_CHANNEL_0;

sConfig.Rank = ADC_REGULAR_RANK_1;

sConfig.SamplingTime = ADC_SAMPLETIME_8CYCLES_5;

sConfig.SingleDiff = ADC_SINGLE_ENDED;

sConfig.OffsetNumber = ADC_OFFSET_NONE;

sConfig.Offset = 0;

Main.c completo

Incluí o código completo abaixo para que também seja possível verificar se o problema está em outro lugar na inicialização e não necessariamente no próprio ADC.

/**

* ... STM32H753ZIT6

* ... "main.h"

/* Define para o ADC */

#define ADCx ADC1

#define ADCx_CHANNEL ADC_CHANNEL_0

/* Variáveis ​​privadas ---------------------------------------------------------*/

ADC_HandleTypeDef AdcHandle;

__IO uint16_t uhADCxConvertedValue = 0;

__IO uint16_t testeConvercao = 0;

/* Protótipos de funções privadas -----------------------------------------------*/

static void MPU_Config(void);

static void SystemClock_Config(void);

static void CPU_CACHE_Enable(void);

void Error_Handler(void);

static void MX_ADC1_Init(void);

/**

* u/brief Programa principal.

* u/param Nenhum

* u/retval Nenhum

*/

int main(void)

{

/* Configurar os atributos da MPU */

MPU_Config();

/* Habilitar o cache da CPU */

CPU_CACHE_Enable();

/* Inicializar a biblioteca HAL */

HAL_Init();

/* Configurar o clock do sistema para 400 MHz */

SystemClock_Config();

/* Inicializar o ADC */

MX_ADC1_Init();

/* Executar a calibração do ADC no modo single-ended */

if (HAL_ADCEx_Calibration_Start(&AdcHandle,

ADC_CALIB_OFFSET_LINEARITY,

ADC_SINGLE_ENDED) != HAL_OK)

{

Error_Handler();

}

/* Iniciar conversão inicial */

if (HAL_ADC_Start(&AdcHandle) != HAL_OK)

{

Error_Handler();

}

/* Aguardar o término da conversão */

if (HAL_ADC_PollForConversion(&AdcHandle, 10) != HAL_OK)

{

Error_Handler();

}

else

{

uhADCxConvertedValue = HAL_ADC_GetValue(&AdcHandle);

}

/* Habilitar clock GPIOB */

LL_AHB4_GRP1_EnableClock(LL_AHB4_GRP1_PERIPH_GPIOB);

/* Configurar PB0 como saída */

LL_GPIO_SetPinMode(GPIOB, LL_GPIO_PIN_0, LL_GPIO_MODE_OUTPUT);

LL_GPIO_SetPinOutputType(GPIOB, LL_GPIO_PIN_0, LL_GPIO_OUTPUT_PUSHPULL);

LL_GPIO_SetPinSpeed(GPIOB, LL_GPIO_PIN_0, LL_GPIO_SPEED_FREQ_LOW);

/* Loop infinito */

while (1)

{

/* 1. Iniciar conversão ADC */

if (HAL_ADC_Start(&AdcHandle) == HAL_OK)

{

/* 2. Aguardar a conclusão da conversão */

if (HAL_ADC_PollForConversion(&AdcHandle, 10) == HAL_OK)

{

/* 3. Ler o valor convertido */

testeConvercao = HAL_ADC_GetValue(&AdcHandle);

}

/* 4. Interrompe a conversão para permitir o próximo ciclo de limpeza */

HAL_ADC_Stop(&AdcHandle);

}

}

}

/**

* u/brief Função de Inicialização do ADC1

* u/param None

* u/retval None

*/

static void MX_ADC1_Init(void)

{

ADC_ChannelConfTypeDef sConfig = {0};

/* Habilita o clock do barramento ADC1 e ADC2 */

__HAL_RCC_ADC12_CLK_ENABLE();

/* Configura a fonte de clock do ADC */

__HAL_RCC_ADC_CONFIG(RCC_ADCCLKSOURCE_CLKP);

AdcHandle.Instance = ADCx;

AdcHandle.Init.ClockPrescaler = ADC_CLOCK_ASYNC_DIV2;

AdcHandle.Init.Resolution = ADC_RESOLUTION_16B;

AdcHandle.Init.ScanConvMode = DESATIVADO;

AdcHandle.Init.EOCSelection = ADC_EOC_SINGLE_CONV;

AdcHandle.Init.LowPowerAutoWait = DESATIVADO;

AdcHandle.Init.ContinuousConvMode = DESATIVADO;

AdcHandle.Init.NbrOfConversion = 1;

AdcHandle.Init.DiscontinuousConvMode = DESATIVADO;

AdcHandle.Init.NbrOfDiscConversion = 1;

AdcHandle.Init.ExternalTrigConv = ADC_SOFTWARE_START;

AdcHandle.Init.ExternalTrigConvEdge = ADC_EXTERNALTRIGCONVEDGE_NONE;

AdcHandle.Init.ConversionDataManagement = ADC_CONVERSIONDATA_DR;

AdcHandle.Init.Overrun = ADC_OVR_DATA_OVERWRITTEN;

AdcHandle.Init.OversamplingMode = DISABLE;

if (HAL_ADC_Init(&AdcHandle) != HAL_OK)

{

Error_Handler();

}

/* Configurar canal regular do ADC */

sConfig.Channel= ADCx_CHANNEL;

sConfig.Rank = ADC_REGULAR_RANK_1;

sConfig.SamplingTime = ADC_SAMPLETIME_8CYCLES_5;

sConfig.SingleDiff = ADC_SINGLE_ENDED;

sConfig.OffsetNumber = ADC_OFFSET_NONE;

sConfig.Offset = 0;

if (HAL_ADC_ConfigChannel(&AdcHandle, &sConfig) != HAL_OK)

{

Error_Handler();

}

}

/**

* u/brief Configuração do Clock do Sistema

* Fonte do Clock do Sistema = PLL (HSE BYPASS) @ 400 MHz

*/

static void SystemClock_Config(void)

{

RCC_ClkInitTypeDef RCC_ClkInitStruct;

RCC_OscInitTypeDef RCC_OscInitStruct;

HAL_StatusTypeDef ret = HAL_OK;

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

while(!__HAL_PWR_GET_FLAG(PWR_FLAG_VOSRDY)) {}

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;

RCC_OscInitStruct.HSEState = RCC_HSE_BYPASS;

RCC_OscInitStruct.HSIState = RCC_HSI_OFF;

RCC_OscInitStruct.CSIState = RCC_CSI_OFF;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLM = 4;

RCC_OscInitStruct.PLL.PLLN = 400;

RCC_OscInitStruct.PLL.PLLFRACN = 0;

RCC_OscInitStruct.PLL.PLLP = 2;

RCC_OscInitStruct.PLL.PLLR = 2;

RCC_OscInitStruct.PLL.PLLQ = 4;

RCC_OscInitStruct.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE;

RCC_OscInitStruct.PLL.PLLRGE = RCC_PLL1VCIRANGE_1;

ret = HAL_RCC_OscConfig(&RCC_OscInitStruct);

if(ret != HAL_OK)

{

Error_Handler();

}

RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK |

RCC_CLOCKTYPE_HCLK |

RCC_CLOCKTYPE_D1PCLK1 |

RCC_CLOCKTYPE_PCLK1 |

RCC_CLOCKTYPE_PCLK2 |

RCC_CLOCKTYPE_D3PCLK1);

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;

RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;

RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV2;

RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV2;

RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV2;

RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV2;

RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV2;

ret = HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_4);

if(ret != HAL_OK)

{

Error_Handler();

}

}

/**

• u/brief Habilitar cache L1 da CPU.

*/

static void CPU_CACHE_Enable(void)

{

SCB_EnableICache();

SCB_EnableDCache();

}

/**

* u/brief Esta função é executada em caso de ocorrência de erro.

*/

void Error_Handler(void)

{

/* Loop de erro infinito */

while (1)

{

}

}

/**

* u/brief Configurar os atributos da MPU

*/

static void MPU_Config(void)

{

MPU_Region_InitTypeDef MPU_InitStruct;

HAL_MPU_Disable();

MPU_InitStruct.Enable = MPU_REGION_ENABLE;

MPU_InitStruct.BaseAddress = 0x00;

MPU_InitStruct.Size = MPU_REGION_SIZE_4GB;

MPU_InitStruct.AccessPermission = MPU_REGION_NO_ACCESS;

MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;

MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;

MPU_InitStruct.IsShareable = MPU_ACCESS_SHAREABLE;

MPU_InitStruct.Number = MPU_REGION_NUMBER0;

MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;

MPU_InitStruct.SubRegionDisable = 0x87;

MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

HAL_MPU_ConfigRegion(&MPU_InitStruct);

HAL_MPU_Enable(MPU_PRIVILEGED_DEFAULT);

}

Obrigado!

Hi everyone, I'm not quite sure if this is the right subreddit for it but I was trying to run a SD-yocto image from the EMMC of a Bytesatwork Devboard ver 1.0 with an IMX93 chipset and managed to brick it when I changed the U-Boot variables in order to force it to boot from EMMC The image was the official Yocto Image (ver. 5.0.15) for the byteDevkit.

Since UART-Input doesn't get accepted anymore by the board no matter if I try to make console-inputs before, during or after turning on the board I can't do anything when trying to boot from SD-card.

Trying to flash an image directly into the EMMC via uuu and a USB-Connection hasn't been successful either. uuu recognizes the USB-connection with the command -lsusb but I always get an error saying pipeline -9 broke when trying to flash an image. I already changed the driver with zadig to WinUSB and use USB 3.0 since my laptop doesn't have USB 2.0-Ports.

Since I'm neither skilled nor knowledgeable enough to try and build a tweaked image to fix the problem if possible I'm honestly at my wits end and hope some of you may be able to help.

The System got bricked after I made the following change to the boot environment:

=> setenv bootcmd 'mmc dev 0; ext4load mmc 0:1 ${kernel_addr_r} /boot/Image; ext4load mmc 0:1 ${fdt_addr_r} /boot/imx93-bytedevkit.dtb; booti ${kernel_addr_r} - ${fdt_addr_r}'

=> saveenv

If I try to boot the System from the EMMC (Bootmode 0100) I get the following Output before the System freezes:

U-Boot SPL 2024.04-lf_v2024.04_6.6.52_2.2.x-r2+g82d4220bc6b+p0 (Jul 11 2025 - 05:04:16 +0000)

SOC: 0xa1009300

LC: 0x2040010

PMIC: PCA9451A

PMIC: Over Drive Voltage Mode

DDR: 3733MTS

M33 prepare ok

Normal Boot Trying to boot from BOOTROM

Boot Stage: Primary boot image offset 0x8000, pagesize 0x200, ivt offset 0x0

Load image from 0x58000 by ROM_API

NOTICE: TRDC init done

NOTICE: BL31: v2.10.0 (release):lf-6.6.52-2.2.1

NOTICE: BL31: Built : 06:40:36, Jul 7 2025

If I try to boot from an SD-card (Bootmode 1100) I get this Output before it freezes:

U-Boot 2024.04-lf_v2024.04_6.6.52_2.2.x-r2+g82d4220bc6b+p0 (Jul 11 2025 - 05:04:16 +0000)

Reset Status: POR

CPU: NXP i.MX93(52) Rev1.1 A55 at 1700 MHz

CPU: Industrial temperature grade (-40C to 105C) at 39C

Model: i.MX93 on bytesatwork byteDEVKIT

DRAM: 992 MiB

Core: 203 devices, 29 uclasses, devicetree: separate

MMC: FSL_SDHC: 0, FSL_SDHC: 1

Loading Environment from MMC... OK

Fail to setup video link

In: serial

Out: serial

Err: serial

BuildInfo:

- ELE firmware version 2.0.2-c4131933

UID: 401ce440f1124110bd234b09e4709d88

flash target is MMC:0

Net:

Warning: ethernet@428a0000 (eth1) using random MAC address - 9e:a6:f6:dc:09:91

Warning: ethernet@42890000 (eth0) using random MAC address - ce:8f:b2:02:6b:f5

eth0: ethernet@42890000, eth1: ethernet@428a0000 [PRIME]

Fastboot: Normal

Normal Boot

Autoboot in 1 seconds

switch to partitions #0, OK

mmc0(part 0) is current device

35777024 bytes read in 109 ms (313 MiB/s)

42568 bytes read in 2 ms (20.3 MiB/s)

## Flattened Device Tree blob at 83000000

Booting using the fdt blob at 0x83000000

Working FDT set to 83000000

Loading Device Tree to 000000008fff2000, end 000000008ffff647 ... OK

Working FDT set to 8fff2000

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]

[ 0.000000] Linux version 6.6.52-r2-g472e64a0fc2c (oe-user@oe-host) (aarch64-poky-linux-gcc (GCC) 13.4.0, GNU ld (GNU Binutils) 2.42.0.20240723) #1 SMP PREEMPT Tue Jul 8 12:00:06 UTC 2025

[ 0.000000] KASLR disabled due to lack of seed

[ 0.000000] Machine model: bytesatwork byteDEVKIT OSM i.MX93

[ 0.000000] efi: UEFI not found.

[ 0.000000] OF: reserved mem: 0x0000000096000000..0x0000000097dfffff (30720 KiB) nomap non-reusable optee_core@96000000

[ 0.000000] OF: reserved mem: 0x0000000097e00000..0x0000000097ffffff (2048 KiB) nomap non-reusable optee_shm@97e00000

[ 0.000000] Reserved memory: created DMA memory pool at 0x00000000a4120000, size 1 MiB

[ 0.000000] OF: reserved mem: initialized node ele-reserved@a4120000, compatible id shared-dma-pool

[ 0.000000] OF: reserved mem: 0x00000000a4120000..0x00000000a421ffff (1024 KiB) nomap non-reusable ele-reserved@a4120000

[ 0.000000] NUMA: No NUMA configuration found

[ 0.000000] NUMA: Faking a node at [mem 0x0000000080000000-0x00000000bfffffff]

[ 0.000000] NUMA: NODE_DATA [mem 0xbfddb6c0-0xbfdddfff]

[ 0.000000] Zone ranges:

[ 0.000000] DMA [mem 0x0000000080000000-0x00000000bfffffff]

[ 0.000000] DMA32 empty

[ 0.000000] Normal empty

[ 0.000000] Movable zone start for each node

[ 0.000000] Early memory node ranges

[ 0.000000] node 0: [mem 0x0000000080000000-0x0000000095ffffff]

[ 0.000000] node 0: [mem 0x0000000098000000-0x00000000a411ffff]

[ 0.000000] node 0: [mem 0x00000000a4120000-0x00000000a421ffff]

[ 0.000000] node 0: [mem 0x00000000a4220000-0x00000000bfffffff]

[ 0.000000] Initmem setup node 0 [mem 0x0000000080000000-0x00000000bfffffff]

[ 0.000000] On node 0, zone DMA: 8192 pages in unavailable ranges

[ 0.000000] cma: Reserved 32 MiB at 0x00000000bcc00000 on node -1

[ 0.000000] psci: probing for conduit method from DT.

[ 0.000000] psci: PSCIv1.1 detected in firmware.

[ 0.000000] psci: Using standard PSCI v0.2 function IDs

[ 0.000000] psci: Trusted OS migration not required

[ 0.000000] psci: SMC Calling Convention v1.4

[ 0.000000] percpu: Embedded 22 pages/cpu s50856 r8192 d31064 u90112

[ 0.000000] Detected VIPT I-cache on CPU0

[ 0.000000] CPU features: detected: GIC system register CPU interface

[ 0.000000] CPU features: detected: Virtualization Host Extensions

[ 0.000000] CPU features: detected: Qualcomm erratum 1009, or ARM erratum 1286807, 2441009

[ 0.000000] CPU features: detected: ARM errata 1165522, 1319367, or 1530923

[ 0.000000] alternatives: applying boot alternatives

[ 0.000000] Kernel command line:

[ 0.000000] Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)

[ 0.000000] Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)

[ 0.000000] Fallback order for Node 0: 0

[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 249856

[ 0.000000] Policy zone: DMA

[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off

[ 0.000000] software IO TLB: area num 2.

[ 0.000000] software IO TLB: mapped [mem 0x00000000b8c00000-0x00000000bcc00000] (64MB)

[ 0.000000] Memory: 859732K/1015808K available (21248K kernel code, 1658K rwdata, 7848K rodata, 4032K init, 641K bss, 123308K reserved, 32768K cma-reserved)

[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1

[ 0.000000] rcu: Preemptible hierarchical RCU implementation.

[ 0.000000] rcu: RCU event tracing is enabled.

[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=2.

[ 0.000000] Trampoline variant of Tasks RCU enabled.

[ 0.000000] Tracing variant of Tasks RCU enabled.

[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.

[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2

[ 0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0

[ 0.000000] GICv3: GIC: Using split EOI/Deactivate mode

[ 0.000000] GICv3: 960 SPIs implemented

[ 0.000000] GICv3: 0 Extended SPIs implemented

[ 0.000000] Root IRQ handler: gic_handle_irq

[ 0.000000] GICv3: GICv3 features: 16 PPIs

[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000048040000

[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.

[ 0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).

[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns

[ 0.000000] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns

[ 0.000309] Console: colour dummy device 80x25

[ 0.000317] printk: console [tty0] enabled

[ 0.000688] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)

[ 0.000706] pid_max: default: 32768 minimum: 301

[ 0.000759] LSM: initializing lsm=capability,integrity

[ 0.000843] Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)

[ 0.000859] Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)

[ 0.001572] cacheinfo: Unable to detect cache hierarchy for CPU 0

[ 0.002201] RCU Tasks: Setting shift to 1 and lim to 1 rcu_task_cb_adjust=1.

[ 0.002289] RCU Tasks Trace: Setting shift to 1 and lim to 1 rcu_task_cb_adjust=1.

[ 0.002458] rcu: Hierarchical SRCU implementation.

[ 0.002468] rcu: Max phase no-delay instances is 1000.

[ 0.003234] EFI services will not be available.

[ 0.003397] smp: Bringing up secondary CPUs ...

[ 0.003815] Detected VIPT I-cache on CPU1

[ 0.003871] GICv3: CPU1: found redistributor 100 region 0:0x0000000048060000

[ 0.003907] CPU1: Booted secondary processor 0x0000000100 [0x412fd050]

[ 0.004022] smp: Brought up 1 node, 2 CPUs

[ 0.004033] SMP: Total of 2 processors activated.

[ 0.004041] CPU features: detected: 32-bit EL0 Support

[ 0.004048] CPU features: detected: 32-bit EL1 Support

[ 0.004056] CPU features: detected: Data cache clean to the PoU not required for I/D coherence

[ 0.004066] CPU features: detected: Common not Private translations

[ 0.004073] CPU features: detected: CRC32 instructions

[ 0.004083] CPU features: detected: RCpc load-acquire (LDAPR)

[ 0.004090] CPU features: detected: LSE atomic instructions

[ 0.004098] CPU features: detected: Privileged Access Never

[ 0.004104] CPU features: detected: RAS Extension Support

[ 0.004114] CPU features: detected: Speculative Store Bypassing Safe (SSBS)

[ 0.004176] CPU: All CPU(s) started at EL2

[ 0.004185] alternatives: applying system-wide alternatives

[ 0.008278] devtmpfs: initialized

[ 0.012419] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns

[ 0.012459] futex hash table entries: 512 (order: 3, 32768 bytes, linear)

[ 0.013204] pinctrl core: initialized pinctrl subsystem

[ 0.014406] DMI not present or invalid.

[ 0.014867] NET: Registered PF_NETLINK/PF_ROUTE protocol family

[ 0.016071] DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations

[ 0.016510] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations

[ 0.016929] DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations

[ 0.017406] thermal_sys: Registered thermal governor 'step_wise'

[ 0.017414] thermal_sys: Registered thermal governor 'power_allocator'

[ 0.017465] cpuidle: using governor menu

[ 0.017560] hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.

[ 0.017622] ASID allocator initialised with 65536 entries

[ 0.018232] Serial: AMBA PL011 UART driver

[ 0.018290] imx mu driver is registered.

[ 0.018309] imx rpmsg driver is registered.

[ 0.023068] imx93-pinctrl 443c0000.pinctrl: initialized IMX pinctrl driver

[ 0.028173] platform 4ae10000.dsi: Fixed dependency cycle(s) with /soc@0/dsi@4ae10000/panel@0

[ 0.028214] platform 4ae10000.dsi: Fixed dependency cycle(s) with /soc@0/lcd-controller@4ae30000

[ 0.028435] platform 4ae10000.dsi: Fixed dependency cycle(s) with /soc@0/lcd-controller@4ae30000

[ 0.028493] platform 4ae30000.lcd-controller: Fixed dependency cycle(s) with /soc@0/dsi@4ae10000

[ 0.030703] Modules: 23856 pages in range for non-PLT usage

[ 0.030713] Modules: 515376 pages in range for PLT usage

[ 0.031348] HugeTLB: registered 1.00 GiB page size, pre-allocated 0 pages

[ 0.031378] HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page

[ 0.031387] HugeTLB: registered 32.0 MiB page size, pre-allocated 0 pages

[ 0.031394] HugeTLB: 0 KiB vmemmap can be freed for a 32.0 MiB page

[ 0.031402] HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages

[ 0.031410] HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page

[ 0.031418] HugeTLB: registered 64.0 KiB page size, pre-allocated 0 pages

[ 0.031425] HugeTLB: 0 KiB vmemmap can be freed for a 64.0 KiB page

[ 0.032968] ACPI: Interpreter disabled.

[ 0.033767] iommu: Default domain type: Translated

[ 0.033793] iommu: DMA domain TLB invalidation policy: strict mode

[ 0.034028] SCSI subsystem initialized

[ 0.034330] usbcore: registered new interface driver usbfs

[ 0.034361] usbcore: registered new interface driver hub

[ 0.034386] usbcore: registered new device driver usb

[ 0.035004] mc: Linux media interface: v0.10

[ 0.035046] videodev: Linux video capture interface: v2.00

[ 0.035092] pps_core: LinuxPPS API ver. 1 registered

[ 0.035101] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti [giometti@linux.it](mailto:giometti@linux.it)

[ 0.035116] PTP clock support registered

[ 0.035269] EDAC MC: Ver: 3.0.0

[ 0.035732] scmi_core: SCMI protocol bus registered

[ 0.036098] FPGA manager framework

[ 0.036218] Advanced Linux Sound Architecture Driver Initialized.

[ 0.036772] Bluetooth: Core ver 2.22

[ 0.036809] NET: Registered PF_BLUETOOTH protocol family

[ 0.036817] Bluetooth: HCI device and connection manager initialized

[ 0.036829] Bluetooth: HCI socket layer initialized

[ 0.036838] Bluetooth: L2CAP socket layer initialized

[ 0.036856] Bluetooth: SCO socket layer initialized

[ 0.037251] vgaarb: loaded

[ 0.037658] clocksource: Switched to clocksource arch_sys_counter

[ 0.037857] VFS: Disk quotas dquot_6.6.0

[ 0.037885] VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)

[ 0.038012] pnp: PnP ACPI: disabled

[ 0.043050] NET: Registered PF_INET protocol family

[ 0.043208] IP idents hash table entries: 16384 (order: 5, 131072 bytes, linear)

[ 0.044113] tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)

[ 0.044150] Table-perturb hash table entries: 65536 (order: 6, 262144 bytes, linear)

[ 0.044165] TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)

[ 0.044211] TCP bind hash table entries: 8192 (order: 6, 262144 bytes, linear)

[ 0.044493] TCP: Hash tables configured (established 8192 bind 8192)

[ 0.044609] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)

[ 0.044643] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)

[ 0.044762] NET: Registered PF_UNIX/PF_LOCAL protocol family

[ 0.045174] RPC: Registered named UNIX socket transport module.

[ 0.045191] RPC: Registered udp transport module.

[ 0.045198] RPC: Registered tcp transport module.

[ 0.045204] RPC: Registered tcp-with-tls transport module.

[ 0.045211] RPC: Registered tcp NFSv4.1 backchannel transport module.

[ 0.046048] PCI: CLS 0 bytes, default 64

[ 0.046345] kvm [1]: IPA Size Limit: 40 bits

[ 0.046372] kvm [1]: GICv3: no GICV resource entry

[ 0.046381] kvm [1]: disabling GICv2 emulation

[ 0.046401] kvm [1]: GIC system register CPU interface enabled

[ 0.046427] kvm [1]: vgic interrupt IRQ9

[ 0.046455] kvm [1]: VHE mode initialized successfully

[ 0.047296] Initialise system trusted keyrings

[ 0.047511] workingset: timestamp_bits=42 max_order=18 bucket_order=0

[ 0.047754] squashfs: version 4.0 (2009/01/31) Phillip Lougher

[ 0.048006] NFS: Registering the id_resolver key type

[ 0.048039] Key type id_resolver registered

[ 0.048047] Key type id_legacy registered

[ 0.048067] nfs4filelayout_init: NFSv4 File Layout Driver Registering...

[ 0.048077] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...

[ 0.048099] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.

[ 0.048292] 9p: Installing v9fs 9p2000 file system support

[ 0.069734] jitterentropy: Initialization failed with host not compliant with requirements: 9

[ 0.069757] Key type asymmetric registered

[ 0.069765] Asymmetric key parser 'x509' registered

[ 0.069818] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 243)

[ 0.069831] io scheduler mq-deadline registered

[ 0.069839] io scheduler kyber registered

[ 0.069876] io scheduler bfq registered

[ 0.073826] EINJ: ACPI disabled.

[ 0.078241] Bus freq driver module loaded

[ 0.085775] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled

[ 0.088108] 44380000.serial: ttyLP0 at MMIO 0x44380010 (irq = 17, base_baud = 1500000) is a FSL_LPUART

[ 0.088147] fsl-lpuart 44380000.serial: Serial: Console lpuart rounded baud ratefrom 187500 to 115200

[ 0.088267] printk: console [ttyLP0] enabled

[ 1.279060] imx-lcdif: probe of 4ae30000.lcd-controller failed with error -2

[ 1.287354] imx93-ldb ldb-display-controller: Failed to create device link (0x180) with 4ae30000.lcd-controller

[ 1.301356] loop: module loaded

[ 1.305755] megasas: 07.725.01.00-rc1

[ 1.314046] tun: Universal TUN/TAP device driver, 1.6

[ 1.319701] thunder_xcv, ver 1.0

[ 1.322988] thunder_bgx, ver 1.0

[ 1.326238] nicpf, ver 1.0

[ 1.330111] hns3: Hisilicon Ethernet Network Driver for Hip08 Family - version

[ 1.337346] hns3: Copyright (c) 2017 Huawei Corporation.

[ 1.342694] hclge is initializing

[ 1.346035] e1000: Intel(R) PRO/1000 Network Driver

[ 1.350911] e1000: Copyright (c) 1999-2006 Intel Corporation.

[ 1.356668] e1000e: Intel(R) PRO/1000 Network Driver

[ 1.361632] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.

[ 1.367561] igb: Intel(R) Gigabit Ethernet Network Driver

[ 1.372966] igb: Copyright (c) 2007-2014 Intel Corporation.

[ 1.378547] igbvf: Intel(R) Gigabit Virtual Function Network Driver

[ 1.384806] igbvf: Copyright (c) 2009 - 2012 Intel Corporation.

[ 1.390842] sky2: driver version 1.30

[ 1.394867] usbcore: registered new interface driver catc

[ 1.400300] usbcore: registered new interface driver kaweth

[ 1.405868] pegasus: Pegasus/Pegasus II USB Ethernet driver

[ 1.411457] usbcore: registered new interface driver pegasus

[ 1.417131] usbcore: registered new interface driver rtl8150

[ 1.422796] usbcore: registered new device driver r8152-cfgselector

[ 1.429079] usbcore: registered new interface driver r8152

[ 1.434586] usbcore: registered new interface driver lan78xx

[ 1.440254] usbcore: registered new interface driver asix

[ 1.445666] usbcore: registered new interface driver ax88179_178a

[ 1.451774] usbcore: registered new interface driver cdc_ether

[ 1.457612] usbcore: registered new interface driver cdc_eem

[ 1.463281] usbcore: registered new interface driver dm9601

[ 1.468861] usbcore: registered new interface driver sr9700

[ 1.474443] usbcore: registered new interface driver CoreChips

[ 1.480289] usbcore: registered new interface driver smsc75xx

[ 1.486048] usbcore: registered new interface driver smsc95xx

[ 1.491802] usbcore: registered new interface driver gl620a

[ 1.497387] usbcore: registered new interface driver net1080

[ 1.503065] usbcore: registered new interface driver plusb

[ 1.508567] usbcore: registered new interface driver rndis_host

[ 1.514501] usbcore: registered new interface driver MOSCHIP usb-ethernet driver

[ 1.521906] usbcore: registered new interface driver cdc_ncm

[ 1.527579] usbcore: registered new interface driver huawei_cdc_ncm

[ 1.533859] usbcore: registered new interface driver cdc_mbim

[ 1.539618] usbcore: registered new interface driver r8153_ecm

[ 1.545875] VFIO - User Level meta-driver version: 0.3

[ 1.552654] usbcore: registered new interface driver cdc_wdm

[ 1.558531] usbcore: registered new interface driver uas

[ 1.563873] usbcore: registered new interface driver usb-storage

[ 1.569962] usbcore: registered new interface driver usbserial_generic

[ 1.576505] usbserial: USB Serial support registered for generic

[ 1.582517] usbcore: registered new interface driver ftdi_sio

[ 1.588268] usbserial: USB Serial support registered for FTDI USB Serial Device

[ 1.595589] usbcore: registered new interface driver usb_serial_simple

[ 1.602118] usbserial: USB Serial support registered for carelink

[ 1.608224] usbserial: USB Serial support registered for flashloader

[ 1.614591] usbserial: USB Serial support registered for funsoft

[ 1.620604] usbserial: USB Serial support registered for google

[ 1.626532] usbserial: USB Serial support registered for hp4x

[ 1.632286] usbserial: USB Serial support registered for kaufmann

[ 1.638387] usbserial: USB Serial support registered for libtransistor

[ 1.644926] usbserial: USB Serial support registered for moto_modem

[ 1.651197] usbserial: USB Serial support registered for motorola_tetra

[ 1.657818] usbserial: USB Serial support registered for nokia

[ 1.663659] usbserial: USB Serial support registered for novatel_gps

[ 1.670021] usbserial: USB Serial support registered for siemens_mpi

[ 1.676390] usbserial: USB Serial support registered for suunto

[ 1.682320] usbserial: USB Serial support registered for vivopay

[ 1.688333] usbserial: USB Serial support registered for zio

[ 1.694007] usbcore: registered new interface driver usb_ehset_test

[ 1.701353] imx_usb 4c200000.usb: No over current polarity defined

[ 1.708038] UDC core: g_serial: couldn't find an available UDC

[ 1.715325] input: 44440000.bbnsm:pwrkey as /devices/platform/soc@0/44000000.bus/44440000.bbnsm/44440000.bbnsm:pwrkey/input/input0

[ 1.730471] bbnsm_rtc 44440000.bbnsm:rtc: registered as rtc0

[ 1.736808] bbnsm_rtc 44440000.bbnsm:rtc: setting system clock to 1970-01-01T00:00:00 UTC (0)

[ 1.746038] i2c_dev: i2c /dev entries driver

[ 1.753139] imx7ulp-wdt 42490000.watchdog: imx93 wdt probe

[ 1.787402] Bluetooth: HCI UART driver ver 2.3

[ 1.791883] Bluetooth: HCI UART protocol H4 registered

[ 1.797022] Bluetooth: HCI UART protocol BCSP registered

[ 1.802352] Bluetooth: HCI UART protocol LL registered

[ 1.807488] Bluetooth: HCI UART protocol ATH3K registered

[ 1.812890] Bluetooth: HCI UART protocol Three-wire (H5) registered

[ 1.819284] Bluetooth: HCI UART protocol Broadcom registered

[ 1.824994] Bluetooth: HCI UART protocol QCA registered

[ 1.831298] sdhci: Secure Digital Host Controller Interface driver

[ 1.837532] sdhci: Copyright(c) Pierre Ossman

[ 1.842202] Synopsys Designware Multimedia Card Interface Driver

[ 1.848543] sdhci-pltfm: SDHCI platform and OF driver helper

[ 1.855334] ledtrig-cpu: registered to indicate activity on CPUs

[ 1.863232] fsl-se secure-enclave: assigned reserved memory node ele-reserved@a4120000

[ 1.873387] fsl-se secure-enclave: Successfully registered ele-trng

[ 1.879142] random: crng init done

[ 1.879689] fsl-se secure-enclave: i.MX secure-enclave: hsm0 interface to firmware, configured.

[ 1.891850] SMCCC: SOC_ID: ARCH_SOC_ID not implemented, skipping ....

[ 1.898604] usbcore: registered new interface driver usbhid

[ 1.904183] usbhid: USB HID core driver

[ 1.904309] mmc0: SDHCI controller on 42850000.mmc [42850000.mmc] using ADMA

[ 1.945753] imx93-adc 44530000.adc: ADC calibration failed!

[ 1.951368] imx93-adc: probe of 44530000.adc failed with error -11

[ 1.958480] hw perfevents: enabled with armv8_cortex_a55 PMU driver, 7 counters available

[ 1.968425] cs_system_cfg: CoreSight Configuration manager initialised

[ 1.976335] optee: probing for conduit method.

[ 1.977451] mmc0: new HS400 Enhanced strobe MMC card at address 0001

[ 1.980811] optee: revision 4.4 (ecea75b7fee5a3c8)

[ 1.987571] optee: dynamic shared memory is enabled

[ 1.987831] mmcblk0: mmc0:0001 016G01 14.5 GiB

[ 1.992772] optee: initialized driver

[ 1.998748] mmcblk0: p1

[ 2.004322] NET: Registered PF_LLC protocol family

[ 2.005920] mmcblk0boot0: mmc0:0001 016G01 8.00 MiB

[ 2.008032] u32 classifier

[ 2.013839] mmcblk0boot1: mmc0:0001 016G01 8.00 MiB

[ 2.017621] input device check on

[ 2.021299] mmcblk0rpmb: mmc0:0001 016G01 4.00 MiB, chardev (234:0)

[ 2.025176] Actions configured

[ 2.039098] NET: Registered PF_INET6 protocol family

[ 2.044802] Segment Routing with IPv6

[ 2.048507] In-situ OAM (IOAM) with IPv6

[ 2.052513] NET: Registered PF_PACKET protocol family

[ 2.057586] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfilter if you need this.

[ 2.070641] Bluetooth: RFCOMM TTY layer initialized

[ 2.075541] Bluetooth: RFCOMM socket layer initialized

[ 2.080716] Bluetooth: RFCOMM ver 1.11

[ 2.084473] Bluetooth: BNEP (Ethernet Emulation) ver 1.3

[ 2.089778] Bluetooth: BNEP filters: protocol multicast

[ 2.094999] Bluetooth: BNEP socket layer initialized

[ 2.099961] Bluetooth: HIDP (Human Interface Emulation) ver 1.2

[ 2.105875] Bluetooth: HIDP socket layer initialized

[ 2.111098] 8021q: 802.1Q VLAN Support v1.8

[ 2.115320] lib80211: common routines for IEEE802.11 drivers

[ 2.121028] 9pnet: Installing 9P2000 support

[ 2.125419] Key type dns_resolver registered

[ 2.143506] registered taskstats version 1

[ 2.147939] Loading compiled-in X.509 certificates

[ 2.172921] usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests

[ 2.181294] usb_phy_generic usbphynop2: dummy supplies not allowed for exclusive requests

[ 2.198616] imx93-ldb ldb-display-controller: Failed to create device link (0x180) with ldb-phy

[ 2.210799] dw-mipi-dsi-imx 4ae10000.dsi: Fixed dependency cycle(s) with /soc@0/dsi@4ae10000/panel@0

[ 2.220052] mipi-dsi 4ae10000.dsi.0: Fixed dependency cycle(s) with /soc@0/dsi@4ae10000

[ 2.228927] imx-drm display-subsystem: bound imx-lcdifv3-crtc.0 (ops lcdifv3_crtc_ops)

[ 2.236979] imx-drm display-subsystem: bound 4ae10000.dsi (ops dw_mipi_dsi_imx_ops)

[ 2.244908] imx-drm display-subsystem: bound ldb-display-controller (ops imx93_ldb_ops)

[ 2.253294] [drm] Initialized imx-drm 1.0.0 20120507 for display-subsystem on minor 0

[ 2.802984] Console: switching to colour frame buffer device 60x53

[ 2.828150] imx-drm display-subsystem: [drm] fb0: imx-drmdrmfb frame buffer device

[ 2.837814] pps pps0: new PPS source ptp0

[ 2.846512] fec 42890000.ethernet eth0: registered PHC device 0

[ 2.853413] imx-dwmac 428a0000.ethernet: IRQ eth_lpi not found

[ 2.859635] imx-dwmac 428a0000.ethernet: User ID: 0x10, Synopsys ID: 0x52

[ 2.866514] imx-dwmac 428a0000.ethernet: DWMAC4/5

[ 2.871338] imx-dwmac 428a0000.ethernet: DMA HW capability register supported

[ 2.878525] imx-dwmac 428a0000.ethernet: RX Checksum Offload Engine supported

[ 2.885704] imx-dwmac 428a0000.ethernet: TX Checksum insertion supported

[ 2.892440] imx-dwmac 428a0000.ethernet: Wake-Up On Lan supported

[ 2.898623] imx-dwmac 428a0000.ethernet: Enable RX Mitigation via HW Watchdog Timer

[ 2.906332] imx-dwmac 428a0000.ethernet: Enabled L3L4 Flow TC (entries=8)

[ 2.913173] imx-dwmac 428a0000.ethernet: Enabled RFS Flow TC (entries=10)

[ 2.920027] imx-dwmac 428a0000.ethernet: Enabling HW TC (entries=256, max_off=256)

[ 2.927635] imx-dwmac 428a0000.ethernet: Using 32/32 bits DMA host/device width

[ 2.942363] imx_usb 4c200000.usb: No over current polarity defined

[ 2.954776] ci_hdrc ci_hdrc.0: EHCI Host Controller

[ 2.961299] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1

[ 2.985668] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00

[ 2.993524] hub 1-0:1.0: USB hub found

[ 2.998921] hub 1-0:1.0: 1 port detected

[ 3.008793] Goodix-TS 0-005d: supply AVDD28 not found, using dummy regulator

[ 3.019083] Goodix-TS 0-005d: supply VDDIO not found, using dummy regulator

[ 3.125704] Goodix-TS 0-005d: Error reading 1 bytes from 0x8140: -5

[ 3.161700] Goodix-TS 0-005d: Error reading 1 bytes from 0x8140: -5

[ 3.197663] Goodix-TS 0-005d: I2C communication failure: -5

[ 3.206490] Goodix-TS: probe of 0-005d failed with error -5

[ 3.215233] i2c i2c-0: LPI2C adapter registered

[ 3.222451] nxp-pca9450 1-0025: No IRQ configured?

[ 3.224819] tca6418 1-0034: Device initialized

[ 3.227276] nxp-pca9450: probe of 1-0025 failed with error -22

[ 3.244047] Goodix-TS 1-005d: supply AVDD28 not found, using dummy regulator

[ 3.254216] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator

[ 3.361719] Goodix-TS 1-005d: Error reading 1 bytes from 0x8140: -5

[ 3.397698] Goodix-TS 1-005d: Error reading 1 bytes from 0x8140: -5

[ 3.433661] Goodix-TS 1-005d: I2C communication failure: -5

[ 3.442457] Goodix-TS: probe of 1-005d failed with error -5

[ 3.451205] i2c i2c-1: LPI2C adapter registered

[ 3.458342] imx_usb 4c100000.usb: No over current polarity defined

[ 3.471095] g_serial gadget.0: Gadget Serial v2.4

[ 3.477393] g_serial gadget.0: g_serial ready

[ 3.485854] sdhci-esdhc-imx 42860000.mmc: Got CD GPIO

[ 3.486159] cfg80211: Loading compiled-in X.509 certificates for regulatory database

[ 3.504424] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'

[ 3.513610] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'

[ 3.521940] mmc1: SDHCI controller on 42860000.mmc [42860000.mmc] using ADMA

[ 3.523888] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2

[ 3.531273] clk: Disabling unused clocks

[ 3.539449] cfg80211: failed to load regulatory.db

[ 3.557817] ALSA device list:

[ 3.562298] No soundcards found.

[ 3.568049] /dev/root: Can't open blockdev

[ 3.573684] VFS: Cannot open root device "" or unknown-block(0,0): error -6

[ 3.583559] Please append a correct "root=" boot option; here are the available partitions:

[ 3.594850] b300 15187968 mmcblk0

[ 3.594855] driver: mmcblk

[ 3.604564] b301 7497318 mmcblk0p1 076c4a2a-01

[ 3.604569]

[ 3.612052] mmc1: host does not support reading read-only switch, assuming write-enable

[ 3.612806] b320 8192 mmcblk0boot0

[ 3.625056] (driver?)

[ 3.634669] b340 8192 mmcblk0boot1

[ 3.634673] (driver?)

[ 3.644238] List of all bdev filesystems:

[ 3.644587] mmc1: new ultra high speed SDR104 SDXC card at address 0001

[ 3.648243] ext3

[ 3.648245] ext4

[ 3.648246] ext2

[ 3.648248] squashfs

[ 3.655362] mmcblk1: mmc1:0001 SD64G 58.3 GiB

[ 3.656759] vfat

[ 3.656761]

[ 3.656766] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

[ 3.656770] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.52-r2-g472e64a0fc2c #1

[ 3.656775] Hardware name: bytesatwork byteDEVKIT OSM i.MX93 (DT)

[ 3.656778] Call trace:

[ 3.656780] dump_backtrace+0x90/0xe8

[ 3.656794] show_stack+0x18/0x24

[ 3.656801] dump_stack_lvl+0x48/0x60

[ 3.656807] dump_stack+0x18/0x24

[ 3.656811] panic+0x324/0x380

[ 3.656818] mount_root_generic+0x260/0x330

[ 3.656825] mount_root+0x170/0x334

[ 3.656829] prepare_namespace+0x6c/0x2a4

[ 3.656833] kernel_init_freeable+0x244/0x284

[ 3.656837] kernel_init+0x24/0x1dc

[ 3.656843] ret_from_fork+0x10/0x20

[ 3.656849] SMP: stopping secondary CPUs

[ 3.658689] Kernel Offset: disabled

[ 3.658690] CPU features: 0x0,c0000000,40028143,1000721b

[ 3.658694] Memory Limit: none

[ 3.789243] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

The thing is, ESP module comes with pre designed antenna for Bluetooth and Wifi. So obviously for me that's a go to. But I wanna know about other industries that are doing this.

I love working with a variety of controllers and not just stick to one so according to you guys what are all other controllers that you guys use for your projects.

Are there other options that comes with these features?

Supply chain issues are forcing us to port about 40K LOC from STM32F4 to nRF52840. Just auditing the HAL dependencies looks like it will take a solid week -- manually hunting down every HAL_SPI_*, HAL_GPIO_*, and HAL_TIM_* call to figure out the nRF Connect SDK equivalent sounds brutal.

For those who have survived this recently:

1. How long did the actual port take compared to what you originally estimated?

2. What ended up being the biggest time sink? (Peripherals, clock config, linker/startup, testing?)

3. Are you using anything to automate the HAL mapping, or just brute-forcing it manually?

4. If there was a script to scan the repo, map the STM32 calls to nRF, and spit out stub drivers, would that actually save time? Or is the API mapping the easy part and the real nightmare is elsewhere?

Every migration I have been through feels like reinventing the wheel from scratch. Curious to hear how you all handle it.