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

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

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

yunaidejiezi — Wed, 26 Aug 2026 06:23:42 GMT

Hi, @danielmartynek

Thank you for your reply.

The disassembly at 0x00406764 is running in the fls_drv_demo project. The function it actually points to may not be OsIf_SuspendAllInterrupts() from the C40 driver project, but the instructions executed are indeed those for disabling interrupts. I think this function might have been inlined at compile time, since its address is not found in the .map file, so this factor may be irrelevant. Next, I will try to move the functions called internally by c40_ip into the .flash_driver section. In addition, regarding your suggestion to use the Mem_43_InFls MCAL driver, are there any reference examples of making a Flash driver with MCAL? Actually, I have never used MCAL at all.

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

danielmartynek — Wed, 26 Aug 2026 08:53:17 GMT

Hi @yunaidejiezi,

Yes, you need to place all the functions called from the C40_Ip to SRAM.

In the below example, I had to place functions from SchM_Mem_43_INFLS.h to SRAM too.

https://community.nxp.com/t5/S32K-Knowledge-Base/S32K312-C40-Ip-SRAM-RTD-500-DS35/ta-p/2074245

Yes, there is this example in RTD 4.0.0.

Mem_InFls_Example_S32K344

danielmartynek_0-1787734274169.png

Regards,

Daniel

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

yunaidejiezi — Thu, 27 Aug 2026 02:43:43 GMT

Hi,@danielmartynek

Thank you for your reply.

I have opened two projects: Mem_InFls_Example_S32K344 and S32K312_C40_Ip_SRAM_RTD_500_DS35. Now I have discovered a very serious issue: it seems that the RTD version I imported does not contain the Mem_43_INFLS_Driver component. After opening Mem_InFls_Example_S32K344, I could not find Mem_43_INFLS_Driver in the MCAL layer. Also, in the S32K312_C40_Ip_SRAM_RTD_500_DS35 project, it appears that Mem_43_INFLS_Driver is not used (since I did not see any calls to Mem_FLs layer functions in main). However, the RTD folder in the Project Explorer does contain SchM_Mem_43_INFLS.c/.h. In the .map file, functions like SchM_Enter_Mem_43_INFLS_MEM_EXCLUSIVE_AREA_04 are also placed into the SRAM area.

I would like to know: when using C40, is SchM_Mem_43_INFLS.c/.h mandatory to be included? Does C40 internally call functions like SchM_Enter_Mem_43_INFLS_MEM_EXCLUSIVE_AREA_04?
20260827-102145.jpg

There is no Mem_43_INFLS_Driver in the Mem_InFls_Example_S32K344 project

20260827-102152.jpg

This is my RTD version

20260827-102157.jpg

The RTD version of the Mem_InFls_Example_S32K344 project.

20260827-103214.jpg

The RTD version of the S32K312_C40_Ip_SRAM_RTD_500_DS35 project

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

danielmartynek — Thu, 27 Aug 2026 07:23:32 GMT

Hi @yunaidejiezi,

This looks like a compatibility issue. I can see many different RTD versions in the screenshots you posted. Please use a single RTD version per S32DS IDE installation, and the IDE version should match the release notes of the RTD you want to use. You can have multiple S32DS IDE installations if you need to work with more RTD versions.

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

yunaidejiezi — Thu, 27 Aug 2026 08:37:57 GMT

Hi,@danielmartynek

It's possible that my description wasn't clear enough.
The reason multiple versions appear in the screenshots is that I have several projects open at the same time: FLs_drv_demo, Mem_InFls_Example_S32K344, and S32K312_C40_Ip_SRAM_RTD_500_DS35.

For the project I created, the RTD version is as shown in Figure 2 in the previous post: S32K3_RTD_4_0_0_P24_D2405_ASR_REL_4_4_REV_0000_20240515.

The versions of the two projects you recommended to me are:

S32K3_RTD_5_0_0_D2408_ASR_REL_4_7_REV_0000_20241002
S32K3_RTD_6_0_0_QLP04_D2508_ASR_REL_4_7_REV_0000_20250822

My question is: due to the RTD version differences, in the fls_drv_demo project, the Mem_43_INFLS_Driver component is not available in Mcal, and the file SchM_Mem_43_INFLS is not generated in my project. This is clearly shown in the project manager comparison between the two projects in the screenshots below.

20260827-163404.jpg20260827-163400.jpg

Overall, my current RTD version likely does not support developing a flash driver based on the Mem_43_INFLS_Driver. Therefore, I would like to know: for a project that uses the C40 component, is it mandatory to generate the following functions and place them in SRAM?

20260827-163521.jpg

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

danielmartynek — Thu, 27 Aug 2026 10:40:29 GMT

Hi @yunaidejiezi,

Regardless of the RTD version you use, there must be an MCAL FLS driver in the Flash example added by default. If you do not see it there and it cannot be added, there is a problem with the IDE - probably because you have multiple RTD versions in a single IDE installation.

Yes, you also need the SchM_Mem_43_INFLS.h functions in SRAM.

https://community.nxp.com/t5/S32K-Knowledge-Base/S32K312-C40-Ip-SRAM-RTD-500-DS35/ta-p/2074245

BR, Daniel

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

yunaidejiezi — Fri, 28 Aug 2026 01:54:28 GMT

Hi,@danielmartynek

I apologize for the delayed reply.

What I can confirm is that I have never tried installing multiple versions of RTD simultaneously in the IDE. However, it seems that the MCAL FLS driver you mentioned does exist in my setup—just under a different name than Mem_43_INFLS_Driver, so I'm not entirely sure. I've placed it below for reference.

20260828-095254.jpg20260828-095249.jpg

I would like to know whether this component is usable. It does appear to have a built-in feature for automatically placing code into the SRAM region.

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

danielmartynek — Fri, 28 Aug 2026 07:55:52 GMT

Hi @yunaidejiezi,

I see, thank you.

This is because the RTD releases are based on different AUTOSAR specifications.

AUTOSAR 4.4.0 uses the Fls driver, while AUTOSAR 4.7.0 (R21-11) uses Mem_43_INFLS.

The naming convention changed, but the functionality is very similar.

As you mentioned, there is also the option to Load Access Code On Job Start. The Configuration Tool layout is different - the SRAM address configuration is located on a different tab, but otherwise the configuration is equivalent.

Regards,

Daniel