AnsweredAssumed Answered

Busfault in SRAM initialization - AduCM3029

Question asked by luis.possatti on Feb 23, 2018

   Hello, I am using the development kit ADZS-UCM3029EZBRD and I intent to use the SRAM's parity check in my application. Thus I am testing the initialization of the SRAM's memory banks. I am facing the following problem: every time after I initialize the bank 01, a bus fault is flagged by the processor when I try to write to SRAM.

 

   The code I've implemented is presented below (complete code attached):

 

int main(int argc, char *argv[])
{

int dumy_x;
adi_initComponents();
SRAM_init();

volatile int *dummy = (int *) 0x20040000;
*dummy = 0;

while(1)
{
         *dummy = *dummy + 1;
}
return 0;

}

void SRAM_init(void)

{

 

PMG0_TST->SRAM_CTL = BITM_PMG_TST_SRAM_CTL_BNK1EN | BITM_PMG_TST_SRAM_CTL_BNK2EN | BITM_PMG_TST_SRAM_CTL_BNK3EN | BITM_PMG_TST_SRAM_CTL_BNK4EN | BITM_PMG_TST_SRAM_CTL_BNK5EN;
PMG0_TST->SRAM_CTL |= BITM_PMG_TST_SRAM_CTL_STARTINIT; // // triggers the RAM's initialization
while((~(PMG0_TST->SRAM_INITSTAT)) & 0x3F)

{

}

 

}

 

 

I've created the project using the CrossCore 2.6 Project wizard, so the masks I used in function SRAM_init() are defined in the library ADuCM302x.h

 

As I stated, the problems seems to be related exclusively to the bank 01. In this example, the fault is triggered when executing the command *dummy = 0;. I am using a int-pointer instead of a int variable just to control in which SRAM's bank the write will be performed. In this case, it is done outside the bank 01 (address 0x2004_0000), but actually the tests shown that no matters the section of SRAM used, the error is the same.

 

If I disable the initialization of bank 01 and keep all the others banks enable, the problem disappear, independently of the write location defined by the pointer dummy.

 

Note that I am checking the status of the initialization by polling the register PMG0_TST->SRAM_INITSTAT. However, I noticed that the reset address of this register is not the same of the one indicated in the processor's hardware reference, see below:

 

                                                   Reset value of register PMG0_TST_SRAM_INITSTAT

 

 

Reset value of register PMG0_TST_SRAM_INITSTAT in the documentation

 

 

 

In the previous debbuging section, I have initialized all the banks and the value 0x3F stuck, indicating that all the banks are initialized ok. Therefore, it makes my polling check to be bypassed right after the trigger for initialization. In my first thought, this is the source of the error: the verification of successful initialization is bypassed by the stuck flag and I was trying to execute *dummy = 0 before the initialization operation is finished. However, even if I insert a command to abort the initialization in the end of function SRAM_init(), the error remains the same.

 

Can someone give a clue in how to solve this problem?

Outcomes