Questions regarding flashing PFlash for SOTA on TC399

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Roger_Florida
Level 3
Level 3
5 replies posted 5 questions asked 10 sign-ins

I am looking at sample code that demonstrates the flashing algorithm for PFlash with the goal of implementing SOTA updating of the code.

The example loads the various functions for erasing and reprogramming into RAM so that it can be running from RAM during critical stages of reflashing the underlying PFlash but it is a fairly simplistic example which does not address the issues listed below.  Here are a couple of questions:

1. Do these functions need to run out of RAM regardless of which PFlash sectors are being flashed?  For example, if we have divided the PFlash for SOTA, can we run from the lower bank of PFlash while reflashing the upper bank?  Or is the critical region more narrowly defined such as within only the sector being reflashed?

2. This is somewhat dependent on the answer to #1. Since the TC399 is a multicore device and each core can be independently running from somewhere in PFlash, is it necessary to suspend these other cores (or cause them also to run from RAM) to avoid having them run from PFlash during the execution of the reflashing algorithm?

0 Likes
1 Solution
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi Roger,

When flashing bank B, the A should be working normally, otherwise, the advantage of A/B bank will not exist. Of course, the user can halt the bank A when flashing bank B. But that doesn't make sense.

Below is a screenshot for your reference.

111.jpg

 dw

View solution in original post

0 Likes
3 Replies
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi Roger,

For 2), all the cores are running on bank A while flashing bank B. Before bank B successfully programed, bank A will keep full code. So, if any error when programming bank B, a reset will not make system died. ideally the code in bank A will running normally, but in fact it depends. The purpose of A/B swap, is to make the update/switch duration is short. So, if bank A code halts for a long time when bank B being programmed, then the advantage of A/B swap will be lost.

For 1), there is already a function called - A/B bank for SWAP,  so when you program one bank, another one is still complete and fully functional.  The benefit of code run in RAM is that you can judge which bank is complete and which is not. So, you could keep the good bank and program the other one. Once you finish the programming, both the bank is complete, but one bank is newer, then a reset will start the newer version of program.

The demo is just for an example, you could change according your requirement, but the logic should be considered.

Otherwise, please do not underestimate the effort to get a robust SOTA. 

0 Likes

So, just to clarify, for example, lets say that I have several cores running out of PFlash bank A.  Core 0 is in charge of reflashing bank B and is mostly running out of RAM during the process. But core 1 is in charge of accepting new code over a communication channel and is still running out of PFlash in bank A.

This should be okay?  (In other words, cores can be running out of PFlash bank A while bank B is being reflashed).

0 Likes
Di_W
Moderator
Moderator
Moderator
500 solutions authored 1000 replies posted 250 solutions authored

Hi Roger,

When flashing bank B, the A should be working normally, otherwise, the advantage of A/B bank will not exist. Of course, the user can halt the bank A when flashing bank B. But that doesn't make sense.

Below is a screenshot for your reference.

111.jpg

 dw

0 Likes