• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 434 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.

OMAP35xx: SECMODFWERROR error logged on GP device??

Nicolas Vassal
Prodigy 180 points

Other Parts Discussed in Thread: TPS65950, SYSCONFIG

Hello,

in another post I have detailled an issue I have when going back from OFF mode: Re: OMAP3530: global warm reset after wakeup from OFF mode

I have noticed that when the device wakes-up the CONTROL_SEC_ERR_STATUS.SECMODFWERROR[11] bit is set (@0x4800 22E4).

The definition of this register comes from an old version of the 35xx TRM, because this bit have disappeared in the latest TRM versions.

I wonder how this is possible to have such kind of error flag logged on GP device ???

If anyone has an idea ....

Thanks.

 

Nicolas.

  • 0
    TI__Guru* 91125 points

    This is usually because your code is going off into the weeds upon wakeup and maybe accessing an illegal portion of the memory map (at least illegal for the GP device).  You need to double check your wakeup procedure and restore code.  Here is a wiki that has an example program that runs on the EVM.  I have not tried it on Beagle but it should either work as is or be very similar.

    http://processors.wiki.ti.com/index.php/Power_Management_CCS_project_for_OMAP35x_and_AM-DM37x

     

    Regards,

    James

  • 0 in reply to JJD
    Prodigy 180 points

    Hi James,

    thanks for your reply and the link.

    In fact, depending on the sysboot configuration (used for first cold boot), the OFF/wakeup/restoration sequence will pass or fail.

    So it looks like that during ROM code first execution (after poweron reset) something 'critical' is configured differently between the good and the bad case... but I have not been able yet to find what.

    I have dumped all PRCM, SCM, SDRC registers and didn't found significant difference for the moment. The only track I have is that security error logged.

    But as, from what I understood, this error is not supposed to exist on GP devices the documentation about it is very limited!

    If you have more informations about how to get more informations about these kind of security errors I would be very interested!!

    Thanks.

     

    Regards,

    Nicolas.

     

  • 0 in reply to Nicolas Vassal
    TI__Guru* 91125 points

    You may have some differences in the PMIC.  You can program the PMIC to perform certain sequences during sleep modes.  You can check the TPS65950 TRM for details.  This may be why you are seeing different behaviour.  Also check to see that the scratchpad memory is getting programmed correctly.  You can use the code from the wiki as a guide.

    Regards,

    James

     

  • 0 in reply to JJD
    Prodigy 180 points

    James,

    thanks to the informations in the wiki I have been able to solve the problem on EVM board.

    The usb otg was the problem. After boot I have to enable its interafce clock to modify its SYSCONFIG register.

    If I don't do that, the CORE does not actually go in OFF, and when the wakeup event occurs the ROM code restoration process is not executed.

    This still does not work on beagleboard but this must be a similar issue.

    One thing I don't understand about this sysconfig setup.

    Even if the sysconfig of usb otg is not properly configured (set in no-idle), I can see it is in idle/standby mode from CM_CORE_IDLEST1 register.

    This is why I missed this issue ...

    From my understanding, if the IDLEST bits are set in the CORE register, this means that the module is in idle ... Please could you explain where I'm wrong??

    Thanks!

    Regards,

    Nicolas.

  • 0 in reply to Nicolas Vassal
    TI__Guru* 91125 points

    Hi Nicolas, I'm glad you found the issue. 

    You got tripped up on a subtlety of the interaction between the PRCM and the peripheral modules.  The IDLEST registers indicate that the module may be inaccessible, but not necessarily idle.    From the module's point of view, you have to ensure it will go to idle by choosing auto idle, smart idle or force idle (it is different depending on the module).   In your case, you requested an idle from the PRCM (as indicated by CM_CORE_IDLEST1), but it was never acknowledged by the OTG module because it was in no-idle state.  When the acknoledgement happens, the PRCM then knows it can gate the clock to that module.

    The following wiki explains more about debug tips for idle modes:   http://processors.wiki.ti.com/index.php/OMAP35x_Debug_Steps_for_Idle_Entry

     

    Regards,

    James