UCB_SWAP_COPY does not get evaluated in case of invalid UCB_SWAP_ORIG entry

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

cross mob
michaelp
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Hello,

I'm working on implementing SOTA on a TC377 and I noticed that in case UCB_SWAP_ORIG contains an "invalid" entry (e.g. MARKERLx and MARKERHx all set to 0x00000000 but valid CONFIRMATIONLx and CONFIRMATIONHx), the device gets bricked even though UCB_SWAP_COPY might still contain 100% valid data. According to the User Manual, Chapter 6.5.4.3.1, UCB_SWAP_COPY only gets evaluated if its Confirmation code is "ERRORED" or if there's an uncorrectable ECC error (I guess a curruption detected by comparing internal checksum) in UCB_SWAP_ORIG.

So how is the fail-safe way of programming UCBs ORIG and COPY so that it never comes to the case that the controller does not boot even though one of ORIG and COPY might contain valid configuration?

The datasheet unfortunately does not make it 100% clear. The instruction in Chapter 6.5.4.3.1 ("Dual Password UCB ORIG and COPY Re-programming") always refers to erasing the UCB ("Erase ORIG UCB - the confirmation code is erased prior to the content and treated as ERRORED for the installation.") - which is indeed not required unless all 16 entries are full. So by just overwriting CONFIRMATIONHx/-Lx with 0xFFFFFFFF and adding the new entry nothing gets erased and thus in case of something goes wrong during this process the device is bricked and there's no benefit of having the "redundant" - still valid COPY UCB.

Also, all documents (including AP32404) refer to changing COPY prior to ORIG. But how can I validate that COPY is written correctly before writing ORIG (since COPY will not be used as long as ORIG is intact thus no error will be detected).

So what is the correct way of adding new entries to both UCBs without running the risk of bricking the device in case something goes wrong during the process?

0 Likes
1 Solution
Sharath_V
Moderator
Moderator
Moderator
First comment on blog 250 sign-ins 100 replies posted

You basically need to follow the steps given in AP32404 (Pg.21) based on your swap scenario. Failsafe programming comes into picture only w.r.t confirmation codes but NOT necessarily with respect to the other data that you programmed and that may lead to a bricked device. Invalidating an entry is setting all bits to 1, which is anyway possible to do so physically. So, please pick the right scenario to update the entries as per the AP note above (erase and start from COPY or just invalidate the previous entry etc.) and more or less your conclusion is right.

View solution in original post

0 Likes
19 Replies
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored

As long as the UCB_xxx_ORIG contains a valid confirmation code the UCB_xxx_ORIG is used and the UCB_xxx_COPY is ignored. UCB_xxx_COPY is only used when UCB_xxx_ORIG don't has a valid confirmation code. Please note that when both UCB_xxx_ORIG and UCB_xxx_COPY don't contain a valid confirmation code (e.g. both are erased) the device will be locked after reset and can't be used anymore.

0 Likes
michaelp
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

I see that this is the behaviour, but it's also written in the user manual and does not describe the process of re-programming the UCB which has initially been my question.

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

@michaelp wrote:

 

 

So how is the fail-safe way of programming UCBs ORIG and COPY so that it never comes to the case that the controller does not boot even though one of ORIG and COPY might contain valid configuration?


If you erase SWAP with 00000000H but with correct CONFIRMATIONL, it will be bricked according to your described. So it's suggest to erase CONFIRMATIONL first then write SWAP,  until SWAP is correctly written,  then you can write 57B5327FH to CONFIRMATIONL. Do you think it is possible?

0 Likes
michaelp
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

According to Table 205 (Chapter 6.5.4.3.14), this solution may also lead to bricking the device since the SWAP entry will not be evaluated if the CONFIRMATIONL entry is invalid (row 2).

If I:

  1. delete/overwrite/invalidate (the previous) CONFIRMATIONL
  2. Write SWAP MARKERL + MARKERH
  3. Verify MARKERs
  4. Write CONFIRMATIONL + CONFIRMATIONH

then any failure occuring after step 1 will leave the UCB in an invalid state and not to boot. According to Table 205, as long as the global ORIG Confirmation is CONFIRMED/UNLOCKED, there exists no single order where I can change the ORIG UCB so that if a failure occurs during the process I'm backed up by the COPY UCB:

  • If MARKER valid, but no CONFIRMATIONL for that marker exists --> Bricking (row 3 Table 205)
  • If MARKER invalid, but valid CONFIRMATIONL exists --> Bricking (my case from OP)
  • If no MARKER, no CONFIRMATIONL but old CONFIRMATIONL is already invalid --> Bricking (row 2 Table 205)

So the only solution to mitigate this problem will be to make the global CONFIRMATION entry for ORIG UCB invalid/errored prior to changing anything within. This way, we land in the last 4 rows of table 205 and we can make use of the backup COPY UCB.

Unfortunately, there is no way to do this (without erasing the whole UCB sector) since I did not achieve to only change/overwrite the global ORIG Confirmation Flag in 0xAF402FF0 alone. Trying to do this will result in a PVER.

So I'm basically out of ideas how I could achieve having the COPY UCB as a backup (as intended by Infineon I guess) in case something goes wrong during changing the ORIG UCB and leaving it in an invalid state (of any kind).

Regards

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

dw_0-1679023944946.png

 

From above red line marked, if SWAP confirmation and marker is valid in COPY, then SWAP installed from COPY.

0 Likes
michaelp
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

Yes, I know. But only if UCB_SWAP_ORIG Confirmation State is ERRORED which is not the case for normal reprogramming (entries < 16). The question is how to achieve having an ERRORED Confirmation State in ORIG while reprogramming it?

Regards

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

Please refer to below for ERRORED:

dw_0-1679130049553.png

 

0 Likes
michaelp
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

I know what ERRORED/ERASED values are, but how do I achieve such a state during reprogramming without erasing the whole sector?

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

As all the other data is ERRORED unless CONFIRMED and UNLOCKED, can you try to write something on confirmation code.   Just a suggestion.

0 Likes
Sharath_V
Moderator
Moderator
Moderator
First comment on blog 250 sign-ins 100 replies posted

Hi @michaelp , DFlash page size is 8 bytes, did you try writing 8 bytes (starting from confirmation code start address)? Writing into flash memory also depends on the following boundary condition: you can change the bits from 0 to 1 without erasing but cannot change from 1 to 0 (keep this in mind to achieve the errored state, which is any value other than unlock or confirmed) .

0 Likes

Thanks for your answer.I just checked reprogramming the Confirmation code (and the subsequent 4 Bytes) from 0x43211234 to 0x43211235 (and the subsequent 4 Bytes I left 0x0), which did work (I used the Unlocked value, the Confirmed value should work accordingly). However, there are still issues:

  1. During writePage(), I get a PVER Error. However, the register has changed to 0x43211235 nonetheless.
  2. Again, how do I "get back" to  Confirmed/Unlocked state (after adding the SWAP entry) without requiring an erase of the whole UCB sector. I cannot change the value back to 0x43211234 because of the behaviour you described (change from 1->0 doesn't work).

Regards

0 Likes
Sharath_V
Moderator
Moderator
Moderator
First comment on blog 250 sign-ins 100 replies posted

1. PVER error is expected as you are overwriting the already written bits (0 was already written and you flipped it to 1). It is physically possible to do that, but of course the flash implementation would treat this as error. A success state is writing only into an 'erased' area.

2. You cannot flip 1->0 as it is physically impossible to do so in flash memory. If you need to write back UNLOCKED code, you need to erase the entire sector and reprogram it. 

0 Likes

Hello,

1. Okay, that makes sense to me.

2. Unfortunately, I'm back again at the initial problem. So I conclude that there's basically no way of invalidating the Confirmation flag and I have to always take the risk of a bricked device if something goes wrong during the reprogramming (without erasing) even though there is a perfectly working UCB_SWAP_COPY entry.

The COPY UCBs apparently only serve the purpose of having a redundant copy if either an error occurs during erase / re-instantiating the UCB sector of if an accidental bitflip occurs in the Confirmation flag of the UCB.

0 Likes
Sharath_V
Moderator
Moderator
Moderator
First comment on blog 250 sign-ins 100 replies posted

You basically need to follow the steps given in AP32404 (Pg.21) based on your swap scenario. Failsafe programming comes into picture only w.r.t confirmation codes but NOT necessarily with respect to the other data that you programmed and that may lead to a bricked device. Invalidating an entry is setting all bits to 1, which is anyway possible to do so physically. So, please pick the right scenario to update the entries as per the AP note above (erase and start from COPY or just invalidate the previous entry etc.) and more or less your conclusion is right.

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

You cannot flip 1->0 as it is physically impossible to do so in flash memory. If you need to write back UNLOCKED code, you need to erase the entire sector and reprogram it. 

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

2. Unfortunately, I'm back again at the initial problem. So I conclude that there's basically no way of invalidating the Confirmation flag and I have to always take the risk of a bricked device if something goes wrong during the reprogramming (without erasing) even though there is a perfectly working UCB_SWAP_COPY entry. [Sorry I don't understand that you said no way, you can flip a bit in CONFIRMATION code to make it invalidated.]

The COPY UCBs apparently only serve the purpose of having a redundant copy if either an error occurs during erase / re-instantiating the UCB sector of if an accidental bitflip occurs in the Confirmation flag of the UCB.[Yes]

0 Likes
michaelp
Level 1
Level 1
5 replies posted 5 sign-ins First reply posted

@Di_W wrote:

2. Unfortunately, I'm back again at the initial problem. So I conclude that there's basically no way of invalidating the Confirmation flag and I have to always take the risk of a bricked device if something goes wrong during the reprogramming (without erasing) even though there is a perfectly working UCB_SWAP_COPY entry. [Sorry I don't understand that you said no way, you can flip a bit in CONFIRMATION code to make it invalidated.]


Yes, sorry I was a bit unclear. You're right, it is possible to invalidate the Confirmation before reprogramming, but I cannot really make use of it since I would have to erase the whole sector after I'm done to "re-enable" the UCBs (make it valid again) since ERRORED -> CONFIRMED/UNLOCKED is not possible without erase.

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

@michaelp wrote:

@Di_W wrote:

2. Unfortunately, I'm back again at the initial problem. So I conclude that there's basically no way of invalidating the Confirmation flag and I have to always take the risk of a bricked device if something goes wrong during the reprogramming (without erasing) even though there is a perfectly working UCB_SWAP_COPY entry. [Sorry I don't understand that you said no way, you can flip a bit in CONFIRMATION code to make it invalidated.]


Yes, sorry I was a bit unclear. You're right, it is possible to invalidate the Confirmation before reprogramming, but I cannot really make use of it since I would have to erase the whole sector after I'm done to "re-enable" the UCBs (make it valid again) since ERRORED -> CONFIRMED/UNLOCKED is not possible without erase.[Understood,  now let us go back to the previous question,  if you invalidate the CONFIRMATION flag, then the system will use UCB_SWAP_COPY to boot, and avoid to be bricked even if you are erasing the UCB_SWAP_ORIG. Does it make sense?]


 

0 Likes
MoD
Employee
Employee
50 likes received 500 replies posted 100 solutions authored

As described in the mentioned AP32404 you can invalidate a confirmation code by overwrite with 0xFFFFFFFF. To avoid problems during programming, first program the new swap entry and when this write was ok then invalidate the previous confirmation code. If you had a problem during programming then invalidate the written entry and write a new one.

0 Likes