S32K322 MCAL SRAM SIZE

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K322 MCAL SRAM SIZE

Jump to solution
847 Views
simonliu
Contributor III

S32K322的RAM空间较小,分给双核使用后,SRAM0可用空间就过小。移植MCAL时提示SRAM0空间溢出。是否有方法可以将MCAL 使用的RAM空间调整为使用TCRAM,以节省SRAM。

0 Kudos
Reply
1 Solution
820 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @simonliu 

Yes, it's feasible to move selected MCAL resources to DTCM on S32K3, as the RTD linker script already defines .dtcm_data* and .dtcm_bss* sections mapped to DTCM. This can help free up SRAM, but it must be done carefully. DTCM is tightly coupled to the core, not accessible by DMA, and not shareable across cores or other bus masters like HSE, for example. So placing DMA buffers or shared MCAL data there can break functionality. Only core-local, performance-critical, non-DMA data should be moved. Stack is already placed in DTCM, which is fine. Any changes should be validated with integration tests to ensure no side effects in MCAL drivers.

Regards,
Lukas

View solution in original post

0 Kudos
Reply
1 Reply
821 Views
lukaszadrapa
NXP TechSupport
NXP TechSupport

Hi @simonliu 

Yes, it's feasible to move selected MCAL resources to DTCM on S32K3, as the RTD linker script already defines .dtcm_data* and .dtcm_bss* sections mapped to DTCM. This can help free up SRAM, but it must be done carefully. DTCM is tightly coupled to the core, not accessible by DMA, and not shareable across cores or other bus masters like HSE, for example. So placing DMA buffers or shared MCAL data there can break functionality. Only core-local, performance-critical, non-DMA data should be moved. Stack is already placed in DTCM, which is fine. Any changes should be validated with integration tests to ensure no side effects in MCAL drivers.

Regards,
Lukas

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2183536%22%20slang%3D%22zh-CN%22%20mode%3D%22CREATE%22%3ES32K322%20MCAL%20SRAM%20SIZE%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2183536%22%20slang%3D%22zh-CN%22%20mode%3D%22CREATE%22%3E%3CP%3EThe%20RAM%20space%20of%20S32K322%20is%20small%2C%20and%20after%20dividing%20it%20for%20dual-core%20use%2C%20the%20space%20available%20for%20SRAM0%20is%20too%20small.%20When%20porting%20MCAL%2C%20it%20prompts%20SRAM0%20space%20overflow.%20Is%20there%20any%20way%20to%20adjust%20the%20RAM%20space%20used%20by%20MCAL%20to%20use%20TCRAM%20to%20save%20SRAM.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2183991%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20S32K322%20MCAL%20SRAM%20SIZE%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2183991%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHi%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F165520%22%20target%3D%22_blank%22%3E%40simonliu%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYes%2C%20it's%20feasible%20to%20move%20selected%20MCAL%20resources%20to%20DTCM%20on%20S32K3%2C%20as%20the%20RTD%20linker%20script%20already%20defines%20.dtcm_data*%20and%20.dtcm_bss*%20sections%20mapped%20to%20DTCM.%20This%20can%20help%20free%20up%20SRAM%2C%20but%20it%20must%20be%20done%20carefully.%20DTCM%20is%20tightly%20coupled%20to%20the%20core%2C%20not%20accessible%20by%20DMA%2C%20and%20not%20shareable%20across%20cores%20or%20other%20bus%20masters%20like%20HSE%2C%20for%20example.%20So%20placing%20DMA%20buffers%20or%20shared%20MCAL%20data%20there%20can%20break%20functionality.%20Only%20core-local%2C%20performance-critical%2C%20non-DMA%20data%20should%20be%20moved.%20Stack%20is%20already%20placed%20in%20DTCM%2C%20which%20is%20fine.%20Any%20changes%20should%20be%20validated%20with%20integration%20tests%20to%20ensure%20no%20side%20effects%20in%20MCAL%20drivers.%3C%2FP%3E%0A%3CP%3ERegards%2C%3CBR%20%2F%3ELukas%3C%2FP%3E%3C%2FLINGO-BODY%3E