• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 40 subscribers
  • Views 230 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3220SF-LAUNCHXL: PRCMPeripheralReset(PRCM_WDT) behavior after OTA-Self Test

Naga SuresH
Intellectual 560 points
Part Number: CC3220SF-LAUNCHXL
Other Parts Discussed in Thread: CC3220SF
Hi,
I'm using the following modules for my application.
Amazon FreeRTOS -> 202107 
FreeRTOS Kernel V10.4.3
AWS IoT Over-the-air Update v3.0.0
SL Host Driver Version 2.0.1.27
Service Pack Version sp_3.14.0.0_2.0.0.0_2.2.0.7.bin
  
  
As per my understanding, In OTA -Self Test case, bootloader is taking the control of WDT.
Under ota_pal.c -> WDT Start will be called by following code snippet
prvCreateBootInfoFile
{
    sBootInfo.ulStartWdtTime = CC3220_WDT_CLOCK_HZ * OTA_WDT_TIMEOUT;
    sBootInfo.ulStartWdtKey = CC3220_WDT_START_KEY;
}
 
  
 
Under ota_pal.c -> Reset will be called by following code snippet
otaPal_SetPlatformImageState
{
    PRCMPeripheralReset( ( _u32 ) PRCM_WDT );
}
 
 
Issue:
After the OTA Image commit success, still my application is supposed to send more sensor data and has to go to Hibernate, (without rebooting successful OTA image commit), In this scenario I am facing device hang, and WDT is not recovering, please clarify the following to solve my issue.
 
1.  PRCMPeripheralReset( ( _u32) PRCM_WDT) --> This means WDT is stopping? (If yes that's the reason WDT is not recoverable after WDT reset expected behavior for now) Please clarify on this.
 
2.  If I comment PRCMPeripheralReset function call in OTA Agent, after committing While publishing the sensor data. (If the device hangs also WDT able to recover and working fine).
     By removing this API call and keeping the device directly into Hibernate is there any other impacts on OTA? Is this operation recommended to recover the device? 
 
 
3.  Directly calling the Hibernate function without PRCMPeripheralReset( ( _u32) PRCM_WDT) can stop the WDT? Please refer below Hibernate function call (I mean sl_Stop() will stop the WDT?).
  
 
void CC3220SF_Hibernate (void)
{
    sl_Stop(SL_STOP_TIMEOUT);
    Board_setBurstMode();
    usleep(SLEEP_BEF_HIB_RESET);

    parkPins();
    Power_shutdown(0x0, shutdownTime);
}
 
 
Regards,
Suresh
  • 0
    TI__Guru 61446 points

    The WDT value (prvCreateBootInfoFile) is written to a file (/sys/mcubootinfo.bin). This can happen off-line and even in the factory. 

    When the OTA is completed successfully and sl_Stop is called, the device gets into "TEST Mode".

    When powered up from reset in this mode, the bootloader will automatically set the WDT and run the new image.

    The WDT is being reset only when COMMIT is being performed (this should happen after the app verifies new image). The WDT callback (invoked when the timer expires) or a manual reset without commit would reset the device and revert to the previous working image.

    What are you trying to do after the OTA is complete?

    The MAP_PRCMHibernateCycleTrigger should be used following the successful OTA. Other PRCM API may cause issues due to the device's internal (OTA) state.  

  • 0 in reply to Kobi Leibovitch
    Intellectual 560 points

    Hi Kobi,

      

    Thanks a lot for your response.

     

    Kobi Leibovitch said:
    What are you trying to do after the OTA is complete?

    I am trying to publish data to the cloud after successful commit of the image. Sometimes while publishing the data in this stage (after COMMIT), we are observing device non-recoverable hang, this time WDT is not getting triggered (If I keep PRCMPeripheralReset( PRCM_WDT) API call in OTA AGENT code as is).

      

    If I try to avoid calling PRCMPeripheralReset(PRCM_WDT) just before COMMIT the image in OTA Agent, WDT is able to reset the device if publishing data hang observed. Please see below the code snippet for your reference.

        if( eState == OtaImageStateAccepted )
    {
        PRCMPeripheralReset( ( _u32 ) PRCM_WDT );  /* <<<<<----- Here */ 
        lResult = sl_FsCtl( SL_FS_CTL_BUNDLE_COMMIT, ( _u32 ) 0, ( _u8 * ) NULL, ( _u8 * ) &FsControl, ( _u16 ) sizeof( SlFsControl_t ), ( _u8 * ) NULL, ( _u16 ) 0, ( _u32 * ) NULL );

        if( lResult != 0 )
        {
            LogWarn( ( "Accepted final image but commit failed (%d).", lResult ) );
            mainErr = OtaPalCommitFailed;
            subErr = lResult;
        }
        else
        { /* Success. */
            LogInfo( ( "Accepted and committed final image." ) );
            mainErr = OtaPalSuccess;
        }
    }

    if in case of without hang scenario (success case, after sending the data to cloud), I am using Hibernate function as mentioned the code snippet above (CC3220SF_Hibernate). 

      

    I mean directly I am using CC3220SF_Hibernate API call, and not using any method to stop WDT (MAP_PRCMHibernateCycleTrigger , PRCMPeripheralReset ). 

    Does this work? is my flow correct please clarify.

     

     

    Regards,

    Suresh

  • 0 in reply to Naga SuresH
    TI__Guru 61446 points

    You shouldn't commit once the download is complete. You should first perform sl_Stop and  reset the  (putting the device in "Test Mode" and running the new code) and only when the new code is running and verified - a commit should be called. This is where you should send the response to the cloud (after the update was verified).

    In you case, it seems that you are trying to perform a sequence that was not verified and is not recommended. It seems to me that the commit that you are doing  (when you are not resetting the WDT)  will not do the work and you will end up with the old code (unless you will commit again after the MCU reset and then maybe it will work). 

  • 0 in reply to Kobi Leibovitch
    Intellectual 560 points

    Hi Kobi, 

    Thanks again for your support.

     

    OTA Process we didn't change at all. 

    As explained by you the code flow is the same as below.(in the OTA commit process I am not facing any issues. COMMIT is always getting successful).

     

    1. GET OTA JOB ->> 2.OTA DOWNLOAD ->> 3.RESTART MCU ->> 4.SELFTEST ->> 5.PRCMPeripheralReset(PRCM_WDT)  ->> 6.COMMIT >> 7.Publish large amount of SENSOR data(~137kb ) --> 8.Hibernate

     

    At the stage-7 Publish large amounts of SENSOR data, I am observing the device infinite hang issue. (WDT is not recovering). 

       

    So, without the step-5 (PRCMPeripheralReset(PRCM_WDT)) directly executing 1,2,3,4,6,7,8 steps (removed step-5) devices are able to recover with WDT. by this time OTA image is committed as per the flow OTA side no issue. my only concern is Avoiding the WDT reset (Step-5) causes any problem?

     

    1. GET OTA JOB ->> 2.OTA DOWNLOAD ->> 3.RESTART MCU ->> 4.SELFTEST ->> 5.PRCMPeripheralReset(PRCM_WDT)  ->> 6.COMMIT >> 7.Publish large amount of SENSOR data(~137kb ) --> 8.Hibernate

     

    Regards,

    Suresh

  • 0 in reply to Naga SuresH
    TI__Guru 61446 points

    if you will not reset the WDT it will reset the device when the timeout expires. It was initiated by the bootloader and only meant to protect image in the "test mode". In case the new code doesn't even start or it fails before the commit. 

    If you need a WDT in your application (i.e. after the commit - i'm not sure why the device gets stuck there - you may nay need to check your new code) you can initiate a watchdog from the app. When using watchdog - you'll need to reset it periodically.