How it started

AI writing code is no longer news. When the firmware misbehaves, can it work like an embedded engineer: build, connect a debugger, flash, set breakpoints, step, inspect variables and the call stack, then change the code from what it sees on the board?

Yes. Here is how AutoC plus gdb-debug does that end to end. The target this time is NXP S32K3 (S32K344).

The loop is short:

change MCAL → build_firmware → gdb-connect → restart → breakpoint / step → variables, registers, backtrace → change again → verify

The AI is no longer guessing from source alone. It can attach to the board and check whether init actually ran, whether a driver is doing anything, whether a register has the expected value, and where the program is stuck.

How the AI drives J-Link

The chain:

AutoC → GDB Client → J-Link GDB Server → J-Link → MCU

If you read this far, you already noticed: any debugger that speaks GDB can go through AutoC's gdb-debug skill.

The tools:

Tool	What it does
build_firmware	Build the current firmware
gdb-connect	Start J-Link GDB Server, device=S32K344, SWD
gdb-command restart	Reset → Load → Break → Continue
gdb-command	break / step / continue / locals / print / registers / backtrace

Configure gdb-debug first

Open Settings → Project → Extensions → GDB Debug, and fill in the build command, ELF, GDB client, and J-Link GDB Server paths.

What this S32K344 project used:

Field	Example	Role
Build command	./build.bat	Build firmware
Working directory	empty	Project root
Executable (ELF)	./build/out/main.elf	File to flash and debug
GDB path	D:/NXP/S32DS.3.6.4/S32DS/tools/gdb-arm/arm32-eabi/bin/arm-none-eabi-gdb.exe	Arm GDB from S32DS
GDB target	empty	AutoC starts the GDB Server
GDB server path	D:/Program Files/SEGGER/JLink/JLinkGDBServerCL.exe	J-Link GDB Server
Device	S32K344	Target MCU
Interface	SWD	S32K3 debug interface

Use the paths on your machine. S32K3 uses SWD. If a GDB Server is already running, put its host:port in GDB target.

After save and reload, AutoC registers build_firmware, gdb-connect, and gdb-command.

Build, connect, flash, and run

After a MCAL driver change, run them in sequence:

build_firmware
gdb-connect
restart

build_firmware builds the firmware:

gdb-connect attaches to S32K344 over SWD. restart does Reset / Load / Break / Continue in one shot. The GDB client stays up, so later breakpoints, steps, and variable checks share the same session.

If the build fails, the AI reads the error, changes the code, and builds again. After a clean build, it flashes and starts the next debug round.

An MCAL debug example

MCAL bugs are often not "it failed to compile". They are it compiled, and the hardware still does not behave.

Symptom	Typical suspicion
Port init ran, pin state is wrong	SIUL2 PCR, direction, mux
Dio read/write is wrong	Channel mapping, Port dependency
Can / Spi / Adc / Pwm / Gpt never comes up	Init never reached, clock, IRQ
An IRQ never fires	Vector, priority, enable bit

Those questions end on the real MCU.

Breakpoints, step, inspect

Once attached, do these together:

break Port_Init
break Can_Init
continue
step
locals
print xxx

First check that MCAL init actually entered. Then step through pin setup and register writes. If something is off, inspect locals, config structs, and registers. Typical questions: why is this Channel 0, why is Status still BUSY, is the init parameter wrong.

Call stack

backtrace

This shows which layer you are in. On Uart_SyncSend we captured 7 frames: main → Uart_SyncSend → Uart_StartSyncSend → Uart_Ipw_SyncSend → LPUART IP.

Case: AI debugging AUTOSAR MCAL

Configure UART MCAL and send a message. AutoC already finished the earlier configuration work; that is not the point of this post.

First version of the code

AI starts debugging, flashes, and runs

AI finds the problem

AI changes the MCAL code

Result

From configuration to debug

AutoC used to stop at AI configuring AUTOSAR BSW. After that came the leftover question: does the software actually run?

Now the path continues: configure MCAL → generate code → build → attach J-Link → debug → change code → verify.

The value is not a handful of GDB commands. It is using what the board shows to decide the next step. Chip quirks, timing, and low-level drivers still need an engineer. Build, flash, breakpoints, step, variables, and backtrace, the AI can already take.