How does the RAM get initialized in startup

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

How does the RAM get initialized in startup

1,106 次查看
Ahmed02
Contributor I

Hello,

I am building a project for MPC5748G and I want to use a no init section of memory in the RAM to be able to send messages between different apps and I found this link which EXAMPLE: S32K144 .noinit section usage - NXP Community which explains how to create a no init section but there is something I can't understand which is how the no init memory was initialized but not filled with zeros.

 

What I understand is this part initializes the SRAM but I am not sure whether it fills it with zeros or not: 

;#***************************** Initialise SRAM ECC **************************
;# Store number of 128Byte (32GPRs) segments in Counter
    e_lis       r5, __SRAM_SIZE@h  # Initialize r5 to size of SRAM (Bytes)
    e_or2i      r5, __SRAM_SIZE@l
    e_srwi      r5, r5, 0x7         ;# Divide SRAM size by 128
    mtctr       r5                  ;# Move to counter for use with "bdnz"

;# Base Address of the internal SRAM
    e_lis       r5, __SRAM_BASE_ADDR@h
    e_or2i      r5, __SRAM_BASE_ADDR@l

;# Fill SRAM with writes of 32GPRs
sram_loop:
    e_stmw      r0, 0(r5)           ;# Write all 32 registers to SRAM
    e_addi      r5, r5, 128         ;# Increment the RAM pointer to next 128bytes
    e_bdnz      sram_loop           ;# Loop for all of SRAM

  

and this function is the one that actually clear from the start of ram to end of ram to zeros. Could you please provide further explanation?

0 项奖励
回复
5 回复数

1,084 次查看
petervlna
NXP TechSupport
NXP TechSupport

Hello,

There is a big difference in architecture of those 2 uC.

S32K1 is very simple and has almost no safety features.

For SPC5748G Init of RAM is done for multiple reasons.

1. when power for RAM is lost (destructive reset for example) you will have RAM full of ECC errors.

2. when BIST is executed you will have RAM full of test patterns and full of ECC errors.

Therefore you need to initialize RAM on certain events to clear the ECC faults.

So if you have no init section it is always wise to know if that sections was not affected by above events.

Initialization is simply done as writes to the RAM which will create new data matching the new ECC syndrome in RAM.

What is the target you want to achieve?

Best regards,

Peter

0 项奖励
回复

1,074 次查看
Ahmed02
Contributor I

Hello,

Thanks for your response. What I am trying to do is to define a new section in ram whether in the SRAM or after it where I could send messages between different apps residing in the flash memory. Each app is responsible for some functionalities and at certain points jumps to another app's startup code using this code for example:

__asm__("e_lis %r12,0x00F9");
__asm__("e_or2i %r12,0x8010");
__asm__("e_lwz %r0,0(%r12) ");
__asm__("mtlr %r0");
__asm__("se_blrl");

 

The noinit section must be preserved so I can't define it in the SRAM as it would be initialized to zeros in the startup and if I define it outside the SRAM region when burning the code on the board it enters an IVOR as it trying to access an uninitialized region.

When debugging the whole RAM gets initialized so there are no problems regarding that but in a destructive reset like removing the power from the board and reconnecting it only the SRAM is initialized.

Could you please give me guidance on what should I do to preserve that region? 

0 项奖励
回复

1,058 次查看
petervlna
NXP TechSupport
NXP TechSupport

Hello,

The noinit section must be preserved so I can't define it in the SRAM as it would be initialized to zeros in the startup and if I define it outside the SRAM region when burning the code on the board it enters an IVOR as it trying to access an uninitialized region.

Ok, but your RAM is after power on reset/destructive full of ECC errors. So you have to initialize it.

It just wont keep the data if the power is lost. This is the reason for entering the IVOR when you access un-initialized RAM.

When debugging the whole RAM gets initialized so there are no problems regarding that but

Yes, as the debugger must initialize RAM in his script to be able to load into it the binary required for communication with debugger.

in a destructive reset like removing the power from the board and reconnecting it only the SRAM is initialized.

Could you please give me guidance on what should I do to preserve that region?

To preserve the RAM region trough the loss of supply power to RAM, you cant do anything.

It is how RAM is supposed to work and how it is designed.

For keeping the content trough loss of power there is Flash memory. The MPC5748G offer also EEPROM emulation for such purpose. Like calibration where the data is changed frequently but must be preserved trough loss of power.

Best regards,

Peter

 

0 项奖励
回复

1,049 次查看
Ahmed02
Contributor I

Hello,

Thank you for your response.

Ok, but your RAM is after power on reset/destructive full of ECC errors. So you have to initialize it.

It just wont keep the data if the power is lost. This is the reason for entering the IVOR when you access un-initialized RAM.

I have modified the startup script to initialize my no init but only in the case of destructive reset as I don't want it to clear the memory when jumping between apps as I have stated before the jumping is done by jumping to the value inside cpu0 reset vector

;# Fill SRAM with writes of 32GPRs
sram_loop:
    e_stmw      r0, 0(r5)           ;# Write all 32 registers to SRAM
    e_addi      r5, r5, 128         ;# Increment the RAM pointer to next 128bytes
    e_bdnz      sram_loop           ;# Loop for all of SRAM


    .equ  MC_RGM_DES,    0xFFFA8000      /* Destructive Event Status Register */
    .equ  MC_RGM_POR_MSK, 0x00000001      /* POR flag is bit 0 */
    e_lis   r3, MC_RGM_DES@h
    e_or2i  r3, MC_RGM_DES@l
	e_li    r4,0
    e_lwz   r4, 0(r3)
	/* if POR==0 (warm), skip over the entire clear */

    e_li r6, 1
	and. r4, r4, r6     
    e_beq      skip_clear;

    /* zero the 256 B noinit bank in two 128 B bursts */
    e_lis   r5, __noinit_start__@h
    e_or2i  r5, __noinit_start__@l
    e_li    r6, 2
    mtctr   r6
   	e_li    r0,0
	e_li    r3,0
	e_li    r4,0
	e_li    r6,0

clear_noinit_ecc:
    e_stmw  r0, 0(r5)      ; #write registers R0–R31 128 bytes of zero
    e_stw  r0, 20(r5)
    e_addi  r5, r5, 128    ; #advance pointer by 128
    e_bdnz  clear_noinit_ecc  ; #loop until CTR==0

skip_clear:
	e_li    r5,0

 

Is this conceptually correct to just initialize it here or must I also reinitialize it in that function of the startup.c?

/*FUNCTION**********************************************************************
 *
 * Function Name : init_data_bss
 * Description   : Make necessary initializations for RAM.
 * - Copy the vector table from ROM to RAM.
 * - Copy initialized data from ROM to RAM.
 * - Copy code that should reside in RAM from ROM
 * - Clear the zero-initialized data section.
 *
 * Tool Chains:
 *   __GNUC__           : GNU Compiler Collection
 *   __ghs__            : Green Hills ARM Compiler
 *   __ICCARM__         : IAR ARM Compiler
 *   __DCC__            : Wind River Diab Compiler
 *   __ARMCC_VERSION    : ARMC Compiler
 *
 * Implements    : init_data_bss_Activity
 *END**************************************************************************/
void init_data_bss(void)

 

Best Regards,

Ahmed

0 项奖励
回复

959 次查看
petervlna
NXP TechSupport
NXP TechSupport

Hello,

Is this conceptually correct to just initialize it here or must I also reinitialize it in that function of the startup.c?

You must have initialized RAM at least part you are actively going to use after destructive reset.

It doesn't matter if it is in startup.c or any other file which is executed later in code.

What matter is the before you read RAM (which is after destructive reset full of ECC errors) you make sure such part of RAM is initialized. If not, you will end up in exception.

Best regards,

Peter

0 项奖励
回复