MCX MicrocontrollersのトピックMCX-A346: RAM-based Vector Table Results in HardFault

MCX-A346: RAM-based Vector Table Results in HardFault

ygrayne — Mon, 29 Sep 2025 11:23:30 GMT

I have a RAM-based vector table, properly initialised with valid vectors to handlers in flash memory. Upon executing an SVC instruction, the exception handling escalates to HardFault. It appears that fetching the SVC handler address (LSB set) from the vector table fails. The HardFault handler, though, then does get properly fetched and executed. In this handler, I read the following values.

stack pointer:
SP 0x20027E68

EXC_RETURN 0xFFFFFFA8

stacked LR, PC, and XPSR:
LNKst 0x00004523
PCst 0x00004468
XPSRst 0x69000000

registers:
VTOR 0x20020000
SHCSR 0x00070004
CFSR 0x00000000
HFSR 0x40000000

HFSR indicates a forced (escalated) HardFault.

This is on the bare metal, without the SDK. RAM C0 is used for the test set-up, with the vector table at the bottom and the stack at the top. The (test) SVC handler is minimal, just an infinite loop. I have tested with 45, 60, and 180 MHz system clocks (FIRC, OD core voltage for higher clock rates).

What am I missing? Thanks!

Re: MCX-A346: RAM-based Vector Table Results in HardFault

carlos_o — Mon, 29 Sep 2025 21:27:59 GMT

Hi @ygrayne

Thanks for your post,

The MCX A34x series is a new product so there is not a lot of information about the configuration in low level, I found the following information about the Cortex-M cores Optimizing ARM Vector Table Relocation to RAM with Minimal Memory Overhead you could use it as reference. That information is not tested or validated by NXP, is a Cortex-M generic so you only use it as reference to accomplish your goal. Also, I recommend review the Arm® Cortex®-M33 Processor Technical Reference Manual.

Re: MCX-A346: RAM-based Vector Table Results in HardFault

ygrayne — Sat, 11 Oct 2025 01:52:43 GMT

The problem is that the Cortex-M33 core is not in its reset state as documented by the corresponding reference manual when my program starts to run via its initial PC value (at address 0x04), but PRIMASK = 1, most likely set by the boot ROM code. Consequently, the SVC instruction escalates to HardFault. Resetting PRIMASK to its reset state (CPSIE I) resolves the issue.