S32K144 SRAM address configuration

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

S32K144 SRAM address configuration

跳至解决方案
1,492 次查看
AlexKlose
Contributor I

Hi NXP team,

We are currently using S32K144 and have encountered a problem. Could you please help us solve it? Thanks!

From S32K1xx_Memory_Map.xlsx of the RM, the start address of SRAM_U is 0x2000_0000:

AlexKlose_1-1744941311393.png

Could m_data_2‘s ORIGIN in the link file S32K144_64_flash.ld of S32K144 be set arbitrarily? For example, can it be changed to be less than 0x2000_0000 as following?

AlexKlose_0-1744941218046.png

BTW, we made an initial attempt(change m_data_2‘s ORIGIN to 0x1FFFE000) and confirmed that the compilation could be successfully passed in the S32DS environment, and the generated program could be smoothly downloaded to the S32K144 product board with a normal running status.

 

Thanks, 

Alex

 

0 项奖励
回复
1 解答
1,432 次查看
Senlent
NXP TechSupport
NXP TechSupport

Hi@AlexKlose

There will be no error if you define it this way, and there will be no error if you download it to MCU.
What I want to tell you is that we have some considerations when designing the link file in this way, and it is allocated according to SRAM_L and SRAM_U.
Whether there are potential problems when you modify the link file in this way, you need to do sufficient testing yourself.

在原帖中查看解决方案

0 项奖励
回复
6 回复数
1,467 次查看
Senlent
NXP TechSupport
NXP TechSupport

Hi@AlexKlose

The reason why we define it this way is based on the physical address space of the two blocks of SRAM, which is more reasonable, but you will not get an error if you define it this way.

For s32k144,

the SRAM_L  address range is :0x1FFF8000~0x1FFFFFFF

the SRAM_U address range is: 0x20000000~0x20006FFF

Senlent_0-1744959493231.png

0x1FFFE000 is in the range SRAM_L, but it is not SRAM_U.

 

0 项奖励
回复
1,457 次查看
AlexKlose
Contributor I

Hi Senlent,

Thanks for your quick response.

Since SRAM_L and SRAM_U are two separate physical RAMs, is this operation (m_data_2‘s ORIGIN to 0x1FFFE000) compliant? What risks does it entail? 

"which is more reasonable, but you will not get an error if you define it this way." That means we can still do it this way to expand the space of m_data_2  although this operation is not recommended?

 

Thanks,

Alex

0 项奖励
回复
1,454 次查看
Senlent
NXP TechSupport
NXP TechSupport

Hi@AlexKlose

Usually users may not pay attention to the fact that SRAM_L and SRAM_U are two different blocks.

This needs to be noted when dealing with certain issues, such as ECC processing.

Senlent_0-1744964837520.png

 

0 项奖励
回复
1,444 次查看
AlexKlose
Contributor I

Hi Senlent,

Sorry, I still don't quite understand what you meant in the last post...

I merely want to make sure whether this operation(m_data_2‘s ORIGIN to 0x1FFFE000) itself is legal or not. If not, we would try to optimize the code to reduce the size of the .bss section.

 

Thanks,

Alex

0 项奖励
回复
1,433 次查看
Senlent
NXP TechSupport
NXP TechSupport

Hi@AlexKlose

There will be no error if you define it this way, and there will be no error if you download it to MCU.
What I want to tell you is that we have some considerations when designing the link file in this way, and it is allocated according to SRAM_L and SRAM_U.
Whether there are potential problems when you modify the link file in this way, you need to do sufficient testing yourself.

0 项奖励
回复
1,394 次查看
AlexKlose
Contributor I

Hi Senlent,

OK got it, thanks a lot.

 

Thanks,

Alex

0 项奖励
回复