• State TI Thinks Resolved
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 198 views
  • Users 0 members are here
Support feedback
Options
Options
Related

LAUNCHXL-F28P65X: Unable to enable Lockstep module

Muppidi Satish Kumar
Prodigy 160 points

Part Number: LAUNCHXL-F28P65X
Other Parts Discussed in Thread: C2000WARE

Hello,

I would like to enable Lockstep module (ofcourse compare enable) on Launchpad F28P65x. I referred Technical reference manual (https://dev.ti.com/tirex/explore/node?isTheia=false&node=A__AMkAGl.8suzL8XPB0e3brQ__c2000ware_devices_package__coGQ502__LATEST) Lockstep Compare Module sectionand followed as per the TRM

image.png

My code implementation is

image.png

After calling "vEnableLcm()" function, I called "u8IsLcmLock()" to see whether LCM module enabled or not. Unfortunately, this function returns 0 (not enabled). I am not checking with debug connection. I used printf() to see the status.

Please help me to correct it.

  • 0
    Prodigy 160 points

    I realized that setting LSEN bit is done wrongly. I corrected as below

    /* Lock the LSEN configuration */
        HWREG(CPUSYS_BASE + SYSCTL_O_CPUSYSLOCK2) |= SYSCTL_CPUSYSLOCK2_LSEN;
    And also noticed that the driver library file "lcm.h" contents are suppressed with conditional macro "__TMS320C28XX__" . I tried to define it manually but compilation error throws "this is pre-defined, redefining ignored". i am not able to see where it is defined, if it is defined then why contents of lcm.h are grayed? 
    I copied required content from lcm.h to my application as follows, but the issue remains same,
    Please help in resolving this issue. 
    PC: I just want to enable the LCM module and see whether it is enabled or not. self-tests are not yet included.
  • 0 in reply to Muppidi Satish Kumar
    TI__Guru 55145 points

    Just to confirm, are you running this code from CPU2? I don't think CPU1 has access to these registers. Can you try reading HWREG(CPUSYS_BASE + SYSCTL_O_LSEN) and confirming it returns 1? It should be set by default at reset, but you could double check.

    __TMS320C28XX__ is defined by the compiler automatically. It's basically there in the code to prevent users from trying to call the functions from a non-C28 core (e.g. the functions won't work on the CLA). I suspect CCS is showing them as grayed out because it can't find __TMS320C28XX__ in the code itself. It's unaware that the compiler will define it during the build.

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 160 points

    Hello Whitney,

    Whitney Dewey said:
    are you running this code from CPU2? I don't think CPU1 has access to these registers.

    No, I missed this. I am running this enable logic from CPU1. Now I commented this code. didn't do any new code for CPU2 since by default it will be enabled

    Whitney Dewey said:
    Can you try reading HWREG(CPUSYS_BASE + SYSCTL_O_LSEN) and confirming it returns 1? It should be set by default at reset, but you could double check.

    I did this one alone in CPU1. still this read operation is returning 0. Later I performed write operation 

    Could you please elaborate the steps to enable LCM?
  • 0 in reply to Muppidi Satish Kumar
    TI__Guru 55145 points

    It's as it says in the TRM. You just need to run the steps from CPU2.

    • LSEN.Enable = 1 (should already be set by default, but you can set it explicitly if you want)
    • CPUSYSLOCK2.LSEN = 1 (locks the LSEN register to prevent it from being cleared inadvertently)
    • LCM_CONTROL.CMPEN = 1 (enables lockstep compare)
    • Read LCM_STATUS.LSEN if you want confirm it's enabled

    You can use the driverlib functions to do this as follows

    • SysCtl_enableLockStep
    • SysCtl_lockSysConfig
    • LCM_enableLockstepCompare
    • LCM_isLockStepEnabled

    Whitney

  • 0 in reply to Whitney Dewey
    Prodigy 160 points

    Ok, I understand that I need to create new CPU2 project and add these steps for enabling the LCM compare. All my application executes on CPU1, CPU-1 should know the LCM status. How to achieve this? As per my knowledge, I see that following options available

    1. LCM_STATUS.LSEN is under CPU sub system, so CPU-1 can read the status. But how CPU1 knows that CPU2 is already enabled it?

    2. Should I use IPC to exchange information from CPU2 to CPU1?

    Please suggest me any standard/simple approach available for this.

    Once LCM enabling by CPU2 and status known to CPU1, what is the schema for LCM error handling? should CPU1 or CPU2 handle? Executing self-test (failure insertion) for LCM is also a question I have.

  • 0 in reply to Muppidi Satish Kumar
    TI__Guru 55145 points

    I'm not sure if CPU1 is able to read the LCM_STATUS.LSEN bit, but you can try it. Using an IPC flag for CPU2 to communicate to CPU1 that LCM is enabled, passes self-tests, etc...is probably a better way.

    When it comes to error handling, errors detected by LCM will generate an NMI to both CPU1 and CPU2. You can actually see this happen in the debugger if you use the LCM test modes for error forcing and register parity errors.

    I recommend checking out the SDL for F28P65x. There's an example that uses SDL functions to do LCM tests in <C2000Ware>/libraries/diagnostic/f28p65x/examples/test_application

    Whitney