• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 463 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F28377D: LPMSTAT register wrong value when testing RAM

Alain Felici
Intellectual 320 points

Part Number: TMS320F28377D

Hello, 

In our project, we want to put the CPU2 in stanby mode and check this state periodically thanks to LPMSTAT register (should by equal to 2).

At the beginning, this works, but after testing GS0 RAM, LPMSTAT goes to 0. Therefore, impossible to know if CPU2 is in stanby mode. 

Hereafter, the code used to test the RAM :

#pragma DATA_SECTION(test_ram_GS0,"TestRAM_GS0_sec");
volatile Uint32 test_ram_GS0;

test_ram_GS0 = 0xA5A5A5A5;

EALLOW;

MemCfgRegs.GSxTEST.bit.TEST_GS0 = 0x02 ;

test_ram_GS0 ^= 0X01;

NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;

MemCfgRegs.GSxTEST.bit.TEST_GS0 = 0x00 ;

NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;

EDIS;

if (test_ram_GS0 != pattern)  /* The LPMSTAT register goes to zero here */ 

test_ram_fail |= TEST_RAM_FAIL_GS0;

NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;NOP;

if (MemoryErrorRegs.UCERRFLG.all != 0X0001 )

test_ram_fail |= TEST_RAM_FAIL_GS0;

EALLOW;

MemoryErrorRegs.UCERRCLR.all = 0X0001;

EDIS;

How to solve this issue. 

Thanks for your help

Alain 

The folowing code is used for putting the CPU2 in standby mode (nothing else):

__asm(" EALLOW");

WdRegs.SCSR.all = 0x2; /* WDRST enable, no WDOVERRIDE */ /* ????????? */

WdRegs.WDCR.all = 0x68; /* WDCLK = INTOSC1/512/1, WD disable */ /* ????????? */

CpuSysRegs.LPMCR.bit.LPM = 0b01; /* Configure CPU to go in standby when instruction IDLE is executed */

CpuSysRegs.CPUSYSLOCK1.bit.LPMCR = 1; /* Lock LPM register set above */

__asm(" EDIS");

__asm(" IDLE"); /* IDLE to go in standby mode */

  • 0
    TI__Guru** 116881 points

    Alain,

    It look like CPU2 is waking up from the STABDBY due to some interrupt. When you test GS0, you are creating single bit error or double bit error? And do you have single bit error interrupt enable?

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 320 points

    Vivek, 

    I am creating a single bit error. 

    The NMI interrupt is raised in CPU1, but is disabled in CPU2. 

    It seems, that when NMI is disabled in CPU1, LPMSTAT stay at 2 (correct). I cannot understant relationship between CPU1 NMI and CPU2.

    I need to have NMI enable during RAM testing because I need to check if NMI is raised in case of RAM error. 

    Thanks for your help 

  • 0 in reply to Alain Felici
    TI__Guru** 116881 points

    Alain,

    Ok. for GSx RAM, single bit error will generate NMI because it's a PARITY RAM. I'll look into this further and get back to you. We may need a sample project from you to run it on our setup.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 320 points

    Vivek,

    I have build a sample workspace reduces to the minimum. The CPU2 is going immediately in STDBY mode. The CPU1 wait until the CPU2 is in STDBY mode, set the GPIO143, test the RAM, and set the GPIO144 if the CPU2 is stil in STDBY. 

    We can see on the scope that the GPIO143 is set and the GPIO144 is clear, meaning that the LPMSTAT has changed during the RAM test. 

    Alain https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/4152.TEST.7z

  • 0 in reply to Alain Felici
    TI__Guru** 116881 points

    Hi Alain,

    Sorry for late reply. I could not compile this project because of some missing files. I am still trying to reproduce it at our end. Mean while if you have any further update on this, please let us know.

    Regards,

    Vivek Singh

  • 0 in reply to Vivek Singh
    Intellectual 320 points

    Hello Vivek, 

    Thanks for your answer. I have double check the workspace and modified it. I have removed all external file references, and it can be built alone. 

    Let me know if you need something else. 

  • 0 in reply to Alain Felici
    TI__Guru** 116881 points

    Alain,

    I was able to check this and your observation is correct but this is expected behavior as per TRM. Following is snapshot from TRM.

    In this case NMI on CPU1 is waking up CPU2 from standby. Hope this is clear.

    Regards,

    Vivek Singh