LAUNCHXL-CC3235SF: OTA /sys/mcuflashimg.bin with SL_FS_WRITE_BUNDLE_FILE doesn't take effect

Hi Will,

What is the exact error you see?

With the latest SP, we do see that the error notifications are missing (when installing CC3220 SP on CC3235 device - is that your case?) but the device doesn't seems to get stuck. It automatically revert to the old (working) versions.

If you are using the FreeRTOS OTA, please note that this was developed by the AWS team. Please try to check in their forum for a solution.

Br,

Kobi

Hi Kobi,

Thanks, this issue is specific to the device and does not relate to AWS FreeRTOS. The device hangs in PRCMHibernateCycleTrigger() as described in the original thread. To be clear, this is the issue: resetting the device programmatically is unreliable.

We confirmed the device hangs in PRCMHibernateCycleTrigger(), pressing the reset switch manually when this happens allows the device to actually reset as expected. The new firmware image then loads and is committed as expected, no issues here with the newly received firmware image.

To get around this, placing exceedingly large sleeps as folllows seems to help. Any ideas why this is?

vTaskDelay(pdMS_TO_TICKS(3000UL));

err = sl_Stop(500);
if (err != 0) {
  ...
}

vTaskDelay(pdMS_TO_TICKS(3000UL));

PRCMHibernateCycleTrigger()

sl_stop() never returns an error. Additionally, we have a top level watchdog, which occasionally triggers when PRCMHibernateCycleTrigger() is seen to hang which masks this issue, but as you can appreciate we'd like to understand why the resetting process is flaky when filesystem operations have just occurred.

What is the correct way of resetting CC32XX, what are we doing wrong?

Regards,
Will.

Any chance we could get some attention on this issue please?

This is reproducible and is a known problem also recorded here FYI: 

https://github.com/aws/amazon-freertos/issues/1976

Regards,

Will.

Hi Will,

It seems that what you describe is different from the https://github.com/aws/amazon-freertos/issues/1976 since the manual reset loads your new image (the thread mentions that the manual reset causes the image to revert). is that correct? 

I also saw that you are mentioning similar issues with cc3220. Can you describe the exact issue?

There is a known issue that CC3235 doesn't recognize the a wrong service pack (i.e. it will not stop the download or send a warning) and it can cause the new image to fail (without activating the watchdog). so just make sure you OTA image uses the right service pack (of CC3235). 

Please provide NWP logs (see chapter 20.1 in https://www.ti.com/lit/ug/swru455k/swru455k.pdf).

Br,

Kobi

One thing worth to try, is to replace the PRCMHibernateCycleTrigger() with the following 2 commands:

PRCMHibernateIntervalSet(Ticks); // TICK is a number of 32.768 KHz clocks

PRCMHibernateEnter();

The original code uses 160 ticks (~5msec) for the hibernate cycle, so you can try to extend this value.

I'm not familiar with any change to the timing requirement in regards to the CC3235 - but this may help.

Looking at your work-around, did you try shorter delays? specifically, do you really need the delay before the sl_Stop?

Is there any reason you call sl_Stop with 500 ms? Did you try 200?

Thanks Kobi,

The timings suggested make no difference, unfortunately the code alternative suggested does not make a difference either. There is no specific reason for the timings I posed here, other than trial and error to mask the actual failures.

Perhaps I need to be clearer, there are two issues at play, they may relate but this is unknown to me:

1- On CC3235SF, and only CC3235SF, the filesystem rolls back unexpectedly after an OTA, thus failing the OTA as the new binary never boots up, but always the old one. Please see link above. The very same code works on CC3220SF (re-targeted).

2- Reset does not work reliably, on both CC3220SF and CC3235SF. That said, reset consistently fails on CC3235SF, it has never worked for us in the context of OTA.

Have you had a chance to run the Amazon FreeRTOS OTA demo which confirms this issue? To be absolutely clear, this does not appear to be an Amazon FreeRTOS issue and simply relates to Commit/Rollback of the FS + Reset issue.

Kind Regards,

Hi Will,

Thanks for the inputs. I'll try to check the FreeRTOS OTA demo.

Have you tried using the OTA library from the CC32xx SDK?

Br,

Kobi

Yes,

Tarball OTA works by using  net/ota/source/OtaArchive from the SimpleLink SDK on both CC3220SF and CC3235SF, through Amazon FreeRTOS OTA (we wrote our our own OTA PAL for this). 

FW binaries only with a Vendor key as per Amazon FreeRTOS OTA demo does not work on CC3235SF - but does work on CC3220SF!

Thanks for reporting back on your findings using Amazon FreeRTOS OTA demo.

Regards,
Will.

Hi Will,

Currently, I'm still struggling with the freeRTOS OTA instructions, we have some limitations on the TI account within the AWS that prevents us from following all the steps. We are working to solve this.

One thing I noticed is that the AWS guide code instructs the use of SHA1 (at least for the CSR signing, see the "-sha1" option). Please use "-sha256" instead as CC3235 uses the latter hashing algorithm (this is one of the differences from CC3220).

Also the image itself should be signed using SHA256 (i'm still trying to find where this is being defined).

Br,

Kobi

Thanks Kobi,

Interesting, this is a good point and may well relate to what we are seeing, thanks for that. Sadly we need to park our projects and efforts on CC3235SF until we have a resolution on this issue and won't be able to validate this in the mean time.

Kind Regards.
Will.

Hi Will,

I understand. The other issue is in progress but the resolution may take some time.

If you are able to verify the OTA solution, please update this thread.

I will proceed with my attempts to run the Freertos OTA and to reproduce the issue and will update once i can verify this.

Thanks,

Kobi