TMS320F2800157: LCM

Hello Samuel,

Samuel Li said:

why the LCM_STATUS.CMP_FAIL cannot be clear by software reset when the fault occurs?

The register bit has reset source set to "PORESETn". Which means it will only reset if device is power cycled
If you want to maualy clear the status you can force clear using LCM_STATUS_CLEAR Register.

Samuel Li said:

Question 2:Do you have any idea about the reason of the LCM failed when we doing frequent power on and off tests?

What tests are you doing in power-on and off tests ?

It looks like you are forcing compare fail in software ? that would force compare error
Otherwise it could indicate a functional failure in device although lets understand what exactly you are doing as part of the tests and how many units have you tested that show this error ?

Thanks,
Prarthan.

Hi Prarthan,

Yes, I forced CMP1 and CMP2 fail in software test, but I clear the error after check. the test can't  assert LCM_STATUS.CMP_FAIL, so I think it has nothing to do with the self test and force test. 

I have post the Force test and self test code below,

Information supplementation:

If I not do the force test and self test, it also happens，LCM_STATUS.CMP_FAIL=1 frequently when we doing frequent power on and off tests

Samuel,

So you only power on --> enable comparator (LCM_REGS[LCM_CONTROL.CMPEN=1]) --> power off ---> repeat

If above is the case then its a functional failure.

Have you tried this on multiple units ? How frequently are you able to reproduce the CMP_FAIL ?

Thanks,
Prarthan

yes, almost every MCU shall happen this when doing this test, the frequent is unfixed, sometime it's forty minutes, sometimes it's more than 2 hours. 

Samuel,

Thanks for clarification.
Can you send me the code that I can try to replicate on my end

Thanks,
Prarthan

My code is not complex, you can reset MCU to repeat this case after enabling the LCM. my reset resource is SysCtl_simulateReset(SYSCTL_SIMRESET_XRSN);

Hi Samuel ,

So you are not powering cycling the MCU in every iteration just using SIMRESET for XRSn ?

Samuel Li said:

hanks.

From above image it looked like you power-on, off for every iteration.

Can you share the power on off ramp time for the power supply and try relaxing the ramp up and down times, and try the same thing again ?

Thanks,
Prarthan

repeat power on and power off can occur LCM compare fail, repeat reset MCU using SIMRESET also occur LCM compare fail.

What are the possible reasons for the failure of LCM in your opinion? Can you give me some directions for investigation?

Sam,

I will have to try the repeat reset MCU using SIMRESET and let you know if I am able to reproduce the compare error you are seeing.

Thanks,
Prarthan

Also do you have debugger connected when doing the tests or standalone device ?

Thanks,
Prarthan

Sam,

Based on your inputs I am running this code on FLASH on my end, will let you know if I encounter compare fail.

Hello Samuel,

I was able to see the CMP FAIL using above code.

Can you send us the Device part number details on the chip. Maybe a picture of the chip itself for devices you are seeing failure on

Thanks!

F2800157QPHPRQ1

Samuel,

We need to know what version of silicon you are using ?

Revision A or B ? You can find that written on the chip itself

For example as shown below : 

$7A G4

Hi Sam,

I am confirming a few things with design team here
Will get back to you by tomorrow

Thanks

Hi Sam,

I am still working with the design team to see what the cause of the issue is. 

I will update back soon as I get the response from them

Thanks

Hi Sam,

Update from last week.

We are able to reproduce the errors on SIMRESET XRSn generation and finding the rootcause for it.
Will update as soon as we have cause and necessary steps to prevent that from happenning

But we are not able to generate compare error on Power cycle tests
can you confirm if you were able to generate error on power cycles ?

Thanks,
Prarthan

Hi Sam,

We tried few more tests on the same test case.

We found that Compare fail had already occured before enabling compare in the next XRSn cycle.

So the compare error happened between enabling compare fail in previous cycle and the next cycle and investigating on the root cause (could be reset assertion process triggering false error).

So for this case you should follow this workaround to cross verify and proceed further. I have verified this on my end, please check and let me know if this works for you

    if((HWREG(LCM_CPU1_BASE + LCM_O_STATUS) & LCM_STATUS_CMP_FAIL) == 0U )
    {
        HWREG_BP(LCM_CPU1_BASE + LCM_O_CONTROL) |= LCM_CONTROL_CMPEN;
        asm(" RPT #10 || NOP");
        HWREG(CPUSYS_BASE + SYSCTL_O_SIMRESET) = 0xA5A50002;
        asm(" RPT #10 || NOP");
    }
    else
    {
        Compare_error = true;
        // Clear compare fail from previous cycle and enable compare to continue
        HWREG_BP(LCM_CPU1_BASE + LCM_O_STATUS_CLEAR) |= LCM_STATUS_CLEAR_CMP_FAIL;
        asm(" RPT #10 || NOP");
        HWREG_BP(LCM_CPU1_BASE + LCM_O_CONTROL) |= LCM_CONTROL_CMPEN;
        asm(" RPT #10 || NOP");
        HWREG(CPUSYS_BASE + SYSCTL_O_SIMRESET) = 0xA5A50002;
    }

thank you for your reply, I will test it later, the result will share with you next week.

I cleared LCM status before enable LCM, the fault also occurs, this method can not solve this problem, please do further research, thank you.

I test LCM self test and CMP error force test after enable LCM, and then reset the MCU. the fault also occurs.

Why change the SYSDIV will solve this issue? What are the details of the theory? please give me more information, thanks.

if I change  SYSDIV from 1 to 2, do I still need to clear LCM status before enable LCM?

Hi Sam,

If you have sysdiv set to 2 then you do not need to check for status before enable it works without that.
Setting sysdiv to 1 and triggering consecutive resets(in your case SIMRESET.XRSn) have the clock glitch during reset assertion that propagates to comparator and generates the error. Since error occurs during reset assertion its not critical and hence if you want sysdiv to 1 you can follow the status clearing workaround before enable otherwise set sysdiv to 2.

only F2800157 has this issue? does F2800156 has the same issue? in other words, does every TI chip with LCM have this issue?

Sam,
Applicable to all f280015x devices.

Thanks