int_sram_no_cacheable issue

[dhanabharathi]

Hello @nxp ,

    I am using s32k31xevb and RTD 5.0 and i am configured ADC, CAN and PWM module, when I configure SPI module i am getting , 'non_cacheable_bss' will not fit in region 'int_sram_no_cacheable' error. region overflow by bytes 864.

  how to resolve this error? could you provide solution for this.

[Julián_AragónM]

Hi @dhanabharathi,

Size of this section is defined in the linker file.

The int_sram_no_cacheable region is used for data that must stay consistent between the CPU and peripherals, such as DMA buffers. It avoids cache-related issues and ensures reliable memory access for real-time operations.

You could your linker file to allocate more space to the int_sram_no_cacheable region, however, you must make sure the new size does not overlap.

Also, if you are not using the Det module, you can simply delete it from project source directory to free up some space: Solved: S32DS Update RTD5.0 and Compile with non_cacheable_bss overflow error - NXP Community.

Best regards,
Julián

[dhanabharathi]

Hello @Julián_AragónM ,

I have a couple of questions:

1. The scheduler manager and DET files are taking more memory. Is there any way to reduce the size of these scheduler manager files?

2. For memory reallocation, is it possible to take additional size from int_sram? Will this cause any issues?

[Julián_AragónM]

Hi @dhanabharathi,

1. Yes. If you are not using default error tracer (DET), you can simply delete it. You can also reduce tasks/events or services in your scheduler/OS to reduce size.

2. Yes. You can allocate extra space form int_sram, just ensure you do not overlap regions.

Best regards,
Julián

[dhanabharathi]

hello @Julián_AragónM ,

  1. if I remove Det.c file from RTD i am getting compilation error. I no need Det related (det.c) file how to handle this problem?
  2. if I took memory space from int_sram. i am getting HardFaulthandler. how to resolve this problem.?

[Julián_AragónM]

Hi @dhanabharathi,

1. Are you deleting all related Det files? Have you disabled all of the error detection in your modules? If not, the driver may try to include related files:

2. Hard to say without seeing what you modified or where does the hard fault happened, however, please check the .map file compiled by your project, and adjust the link file according to the size of your program.

When adjusting the linker file, pay attention to MPU config and such. I suggest deleting Det.c for now to avoid overflow for now.

Best regards,
Julián

[dhanabharathi]

Hello @Julián_AragónM ,
   
      I am adjusting the linker file like that attached blow. the memory region is not overlapped, but i am getting the hard fault handler issue, while MC_init_clock() function triggering. how resolve this problem? 
     if it is due to MPU problem, how to resolve this problem?

note: In my configuration MPU is disabled.

[Julián_AragónM]

Hi @dhanabharathi,

It seems that the no cacheable area is not aligned on 4KB boundary.

For now, could you try keeping the linker file the same, and simply deleting Det component to see if enough space is freed up? Have you disabled Det in the modules?

int_sram_no_cacheable region should only be used to save specific data buffers of the modules such as MCL, SPI, etc. 

Best regards,
Julián

[dhanabharathi]

Hello @Julián_AragónM ,
   
      I deleted Det related files still I need 4kb space in int_sram_no_cacheable region. 

could you give me aligned on 4KB boundary linker file or give me example for that.

[dhanabharathi]

hello @Julián_AragónM ,

   The linker file adjustment is correct, when I manually disable the S32_MPU->CTRL = 0, I am not getting hard fault error.
   I am using S32 design studio 3.6.0 and RTD 5.0 version. how to solve this vis configuration. kindly provide solution for this problem.

[Julián_AragónM]

Hi @dhanabharathi,

MPU can be disabled with Mpu_M7_Ip_Deinit(). 

Also, most examples have MPU_ENABLED defined as a project symbol:

This initializes the MPU inside SystemInit() function at startup. Keep in mind this removes memory protection, you should update MPU regions to match your linker changes instead of disabling it.

You can refer to ARM documentation:

• ARMv7-M Architecture Reference Manual
• Chapter 6. Memory Protection Unit
• Optional Memory Protection Unit

Best regards,
Julián