Some issues encountered during Flash driver development on S32K344 under the RTD 4.0.0 environment

yunaidejiezi — Tue, 25 Aug 2026 05:17:48 GMT

Hi everyone,

I'm currently working on a Flash driver that runs in SRAM (specifically, in DTCM without cache enabled for convenience). I've run into some issues and would appreciate your insights.

Project background:

I have two projects: one includes the C40 driver, and the other (which I'll call fls_drv_demo) does not. My goal is to compile the driver in the C40-enabled project, place it at address 0x00500000 via the AT linker directive, and then in fls_drv_demo, use memcpy to copy it to the intended DTCM address. After that, I hardcode the function addresses and call them to observe Flash behavior changes for verification.

What I've done so far:

In the C40-enabled project, I placed all C40 IP-layer functions into the .ramcode section and collected them in the flash_driver section.
Custom functions for initialization and programming are placed in the .Fls_Api_Tab section, also collected into flash_driver.
Linker scripts have been modified accordingly.

The current problem:

In the fls_drv_demo project, when I call a function pointer—whether it's Fls_Init or a programming function like

((uint32_t (*)(const uint32_t, const uint8_t*, const uint32_t))(0x2000702C | 1))(0x00540000, flswritearray, 16);

—the execution always jumps to 0x00406764 after some internal IP-layer function completes.

Specifically:

Fls_Init executes successfully.
However, during the write function, after the internal C40_Ip_MainInterfaceSectorErase finishes and is about to return (pop), the PC pointer ends up at 0x00000000.

My suspicion:

I'm wondering whether some internal functions are still being compiled into .text or .mcal.text sections, causing the program to access the wrong stub area and leading to this behavior. Or is there some additional setup step I'm missing?

I'm completely stuck at this point and would really appreciate any suggestions or guidance.

Apologies if the phrasing is a bit off—this was translated with AI assistance. I've attached some screenshots of the project and the issue for reference.

Thanks in advance!

Linker file configuration in the C40 driver project

The .map file (function and stub region address allocation) generated after modifying the linker in the C40 driver project

The specific contents of the fls_drv_demo project

When running the write function (at 0x2000702C), it goes into the internal RTD library function C40_Ip_MainInterfaceSectorErase (at 0x200074EC). At 0x20007502, it jumps to 0x20007B52, and then the PC points to the address stored at 0x20007B54, which is 0x00406764. Subsequently, when executing the pop instruction at 0x00406778, the value of r3 is as shown in the figure, pointing to 0x2001FFD8. 0x2001FFD8 then points to 0x20007BA8, and the value at 0x7BA8 is 0x00000000, causing the program to crash/run away.

Re: Some issues encountered during Flash driver development on S32K344 under the RTD 4.0.0 environme

danielmartynek — Tue, 25 Aug 2026 14:38:54 GMT

Hi @yunaidejiezi,

Based on the disassembly, you forgot to move the OsIf_SuspendAllInterrupts() function to DCTM, all the functions called by the C40_Ip driver must be in DCTM.

I would recommend using the Mem_43_InFls MCAL driver, which handles the copy-to-RAM automatically at runtime and avoids all of this manual dependency tracking.

BR, Daniel

S32KのトピックSome issues encountered during Flash driver development on S32K344 under the RTD 4.0.0 environment

Some issues encountered during Flash driver development on S32K344 under the RTD 4.0.0 environment

Re: Some issues encountered during Flash driver development on S32K344 under the RTD 4.0.0 environme