TRAE vs Claude Code Real-World Test: Who Can Fix an Embedded Memory Overflow?

Background: A Tricky Embedded Memory Overflow Problem

How well do AI programming tools actually perform in embedded development? One developer answered this question through firsthand experience. While developing a Bluetooth peripheral using the NRF52840 Bluetooth module, he added an Event Manager module to pass messages between different Tasks. However, whenever this module was enabled, the microcontroller program would crash. Previous attempts using TRAE+Kimi, GPT-4, and other tools all pointed to "memory overflow," but none could pinpoint the root cause — ultimately chalking it up to "a possible Bug in the RTOS version."

This time, he decided to run a fair comparison: TRAE + DeepSeek^Ad V4 Pro vs Claude Code + DeepSeek V4 Pro — same model, different Agent frameworks — to see which could truly solve this low-level hardware problem.

Experiment Setup and Test Design

Hardware and Toolchain Configuration

• Chip: NRF52840 (ARM Cortex-M4 core)
• Debugger: J-Link, using RTT and SWD for firmware flashing and debugging
• Operating System: Zephyr RTOS
• Development Language: C++ (this is a key foreshadowing detail)
• Model: Both sides used DeepSeek V4 Pro with 1M context window

About NRF52840 and ARM Cortex-M4 Memory Alignment

ARM Cortex-M4 is a 32-bit processor core widely used in embedded systems, with strict requirements for memory access alignment. "8-byte alignment" means that certain data structures or stack frames must have starting addresses that are integer multiples of 8. This requirement stems from ARM's AAPCS (ARM Architecture Procedure Call Standard) specification — at function call boundaries, the stack pointer (SP) must maintain 8-byte alignment, otherwise floating-point operations, SIMD instructions, or certain atomic operations will trigger a Usage Fault exception, causing program crashes. As Nordic Semiconductor's flagship Bluetooth SoC, the NRF52840 integrates a Cortex-M4F (with floating-point unit), making it even more sensitive to alignment. When Zephyr RTOS creates threads, the kernel strictly validates that the stack buffer address passed in meets alignment constraints — any violation triggers a hardware-level exception. This is precisely the underlying physical cause of the crash in this case.

Comparison Rules

Both tools used identical prompts, starting from the same unfixed code repository, independently investigating and fixing the issue. Since only one hardware setup was available, Claude Code went first, followed by TRAE.

Claude Code's Investigation: One Hour of Deep Debugging

Initial Analysis and First Attempt

Claude Code first traced the call chain, finding that the Event Manager's Task stack size was 8192 bytes (8KB), and calculated memory usage for each component in detail: event objects ~50 bytes, Task info ~100 bytes, message queue buffer ~544 bytes, plus the thread stack itself at 8192 bytes — already exceeding the budget.

It suggested expanding the stack to 20KB. After compiling and flashing — still crashing. No serial output, USB device failed to enumerate.

Deep Debugging and the Key Discovery

Claude Code didn't give up. It turned to J-Link for low-level debugging, capturing a Usage Fault exception. Through iterative breakpoint setting, code rollback verification, and minimal test cases, it progressively narrowed down the problem scope.

Ultimately, Claude Code found the true root cause: C++'s new operator allocates memory that doesn't satisfy ARM Cortex-M's 8-byte stack alignment requirement. In Zephyr RTOS, thread stacks have strict alignment constraints, but C++ standard new doesn't guarantee this alignment, causing illegal memory access when threads start.

The Fix and the Design Philosophy Behind k_malloc

The fix required only two changes:

• Replace new with Zephyr's dedicated k_malloc() allocation function
• Replace delete with k_free()

Flash and verify — problem solved, device working normally. The entire process took about 1 hour.

Why Does k_malloc() Solve the Problem?

Zephyr is an open-source real-time operating system under the Linux Foundation, designed specifically for resource-constrained embedded devices. k_malloc() is a heap memory allocation function provided by the Zephyr kernel — its internal implementation automatically ensures that returned addresses satisfy the platform's alignment constraints (typically 8 bytes or higher), while deeply integrating with Zephyr's Memory Protection Unit (MPU) and stack sentinel mechanisms. In contrast, C++ standard library's new operator in bare-metal or RTOS environments typically calls the underlying malloc(), and many embedded toolchain malloc() implementations don't guarantee meeting the RTOS kernel's strict alignment requirements. This is the fundamental reason why Zephyr's official documentation explicitly recommends using k_malloc() over C++ standard allocators in kernel contexts.

TRAE's Investigation: Fast but Somewhat Rough

Round 1: Quickly Producing a "Working" Solution

TRAE's analysis path was roughly the same as Claude Code's — it also identified struct alignment issues and the 8-byte alignment requirement. But in terms of strategy, TRAE was more goal-oriented — it quickly found a "working" solution: moving Event Manager's start call to after on_start, adjusting the thread creation order.

The device did resume working, but this solution didn't meet the actual design requirements. After the developer pressed further, TRAE entered a second round of investigation.

Round 2: Close to the Truth but Taking a Different Path

In further analysis, TRAE also touched on the issue that new might not be suitable in Zephyr, even writing out key clues in its reasoning process. But ultimately it chose a different path: disabling hardware stack protection (Stack Canary).

With stack protection disabled, memory allocated by C++'s new no longer triggers alignment checks, and the device could work normally. TRAE also implemented a software stack sentinel mechanism as a supplement — placing magic values at the bottom of the stack and periodically checking whether they've been corrupted via a system work queue.

Total time was also about 1 hour, but included one "forced termination" and manual follow-up questions.

Stack Canary vs Hardware MPU Protection: The Essential Difference Between Two Mechanisms

Stack protection encompasses two main classes of mechanisms for defending against stack overflow in embedded systems — understanding their differences is crucial for evaluating the risk of TRAE's solution. Stack Canary is a software mechanism inserted by the compiler: a random "sentinel value" is placed before the return address in a function's stack frame.