Flashing via the bootloader with device security enabled does not work

[gerhardgrasruck]

We want to activate the S12ZVML128 device security via the corresponding configuration byte in the flash configuration field, in order to prevent unauthorized reading out of the flash contents (Access by backdoor keys is to be enabled). However, when security is enabled, writing the flash when not using the programmer, but the bootloader (using Vector vFlash) does not work. An error occurs when descending into the bootloader routine.

Initial state of the Flash Configuration Fields, security is not enabled, error does not occur:

0x00FFFE00: 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF 0xFF 0xFF 0xFF 0xFF 0xFF 0x8F 0xFA 0xBE

0x00FFFE10: …..

Security is enabled, error does occur:

0x00FFFE00: 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF 0xFF 0xFF 0xFF 0xFF 0xFF 0x8F 0xFA 0xBD

0x00FFFE10: …..

 Strangely it does work, if other, not directly related, settings in the Flash Configuration Field are modified:

Security is enabled, flash nonvolatile byte (initializes Flash Option Register FOPT)) is set to 0xFF, error does not occur:

0x00FFFE00: 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF 0xFF 0xFF 0xFF 0xFF 0xFF 0x8F 0xFF 0xBD

0x00FFFE10: …..

Security is enabled, EEPROM Protection byte (initializes EEPROM Protection Register DFPROT)) is set to 0Xff, error does not occur:

0x00FFFE00: 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFA 0xBD

0x00FFFE10: …..

Even though it does work with certain modifications, as shown above, we are unsure how reliable the behavior is and would like to have an explanation before proceeding.

[RadekS]

Hi Gerhard,

I prepared for you ECC examples:

The ECC is generated for half phrase (two words) by 39-Bit ECC Scheme.

So, important for us are last four bytes 0xFF 0x8F 0xFA 0xBE.

Data                    ECC

0xFF8FFABE       0x06

0xFF8FFABD       0x05

Since programming change just log1->log0, the result values in flash will be

0xFF8FFABC       0x04

Unfortunately, the ECC do not fit to this data byte combination (The ECC for 0xFF8FFABC is 0x34). Therefore, I suppose that result will be double bit checksum error.

From RM: “If a double bit fault is detected while reading the P-Flash phrase containing the Flash security byte during the reset sequence, all bits in the FSEC register will be set to leave the Flash module in a secured state with backdoor key access disabled.”.

Your second case (0xFF 0x8F 0xFF 0xBD)

Data                     ECC

0xFF8FFFBE        0x18

0xFF8FFFBD        0x1B

Since programming change just log1->log0, the result values in flash will be

0xFF8FFFBC        0x18

In this case, we can see that result ECC will be the same as original and data will change only in one bit. The single bit ECC error will be fixed automatically by ECC state machine and you will read 0xFF8FFFBE – The MCU will stay unsecured even when you want secure it.

Your third case (0xFF 0xFF 0xFA 0xBD)

Data                    ECC

0xFFFFFABE       0x08

0xFFFFFABD       0x0B

Since programming change just log1->log0, the result values in flash will be

0xFFFFFABC       0x08

In this case, we can see that result ECC will be the same as original and data will change only in one bit. The single bit ECC error will be fixed automatically by ECC state machine and you will read 0xFFFFFABE – The MCU will stay unsecured even when you want secure it.

I hope it helps you in explanation of described behaviour.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gerhardgrasruck]

Hello Radek,

thank you very much for your suggestions. But I don't quite understand, how they can lead to the observed behaviour.

I am modifying the values in the .s19 image file, which I then flash as a whole with the usual Codewarrior flash functionality (The flash task includes at the start a chip erase operation). There are no errors reported during flashing, and the ECU then works normally. There is only a problem, when I then try to flash another application image via the bootloader. Your quotation "set to leave the Flash module in a secured state with backdoor key access disabled." seems to indicate that in case of an ECC problem nothing should work anymore? Also, if there was some problem with the ECC, why should only the flash configuration field be affected?

Regards,

Gerhard

[RadekS]

Hi Gerhard,

When you load your code by CW, the debugger will erase whole memory and write all data.

That is OK.

When you load just bootloader into your MCU (or bootloader with application), the project already contains some data at 0x00FFFE08..0x00FFFE0F. When bootloader wants to load new application, it obviously does not erase last P-Flash sector with flash configuration field prior new writing. I guess, that this last sector is occupied by the bootloader.

The cumulative write (rewrite already written data) will cause described behavior.

So, it is obviously an issue in your bootloader (cannot read/modify/write target sector) or in your system design.

In general, it is a bad idea when application and bootloader share any nonvolatile memory range.

The P-Flash areas for bootloader and application should be separated. The application should not contain any data in an area which is occupied by bootloader otherwise the bootloader must have feature for rewrite itself.

Since the smallest area which may be erased is sector (512 bytes in your case), the border between application and bootloader area must be aligned with sectors or your bootloader must contain feature for rewrite itself (inconvenient, in the case of the last sector also potentially dangerous).

Note: potentially dangerous = when we erase the last sector with flash configuration field, interrupt vectors and reset vector and unexpected reset occurs prior we write data back, the MCU will be stuck (bricked) due to missing reset vector.

About double bit fault at 0x00FFFE08..0x00FFFE0F range)

The MCU reads this area during reset sequence. If there is double bit ECC error, the Flash and EEPROM become fully protected and MCU secured.

This is for safety reason, when there is double bit error, we cannot trust to this flash content. This feature prevents against hack attack by using cumulative write for MCU unsecure.

From this point of view, the flash configuration field is quite critical and special area.  

In such case, the CPU will continue in running as usual. But for example, the EEPROM update will not work due to the fact, that protection may be just increased during normal mode.

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gerhardgrasruck]

Sorry for the delayed answer, I was on vacation.

The division of the P-Flash is as follows:

Application: 0xFE0000 - 0xFF9BFF
Bootloader: 0xFF9C00 - 0xFFFDFF
Flash Config: 0xFFFE00 - 0xFFFE0F

I asked the engineers responsible for the bootloader, it only writes to the application area when updating, the Flash Configuration Field is not touched.

Regards,

Gerhard

[RadekS]

Hi Gergard,

Thank you for more details.

The Flash Config is in the same P-Flash sector as default interrupt vectors (0xFFFE10 - 0xFFFFFB) and reset vector (0xFFFFFC - 0xFFFFFF).

So, the Flash Config configuration should be programmed together with interrupt and reset vectors.

If, you want write any data into area 0xFFFE08 - 0xFFFE0F and MCU is unsecured (FSEC at adress 0xFFFE0F=0xFE), you must erase whole sector (0xFFFE00 - 0xFFFFFF) and program Flash Config with interrupt and reset vectors again.

This is potentially dangerous due to potential lost of reset vector value in the case of unexpected reset and we should avoid that situation if possible. In other words: the Flash Config configuration should be written just once - in production.

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gerhardgrasruck]

I made some further investigations:

• It seems that the error is connected with EEPROM protection, which is active when it should not be.
• This is due to the value of the DFPROT register, which is different from the initialisation value in the Flash Configuration Field (e.g. 0x8F->0x0x0F, 0xFF->0x80).
• If the protection bit is set in DFPROT, reading access to the Flash Configuration Field leads to a reset of the ECU.
• The FERSTAT register status indicates that no ECC errors happened

Case 1, Flash Configuration Field with Security enabled, DFPROT init value set to 0x8F:

0x00FFFE00: 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF 0xFF 0xFF 0xFF 0xFF 0xFF 0x8F 0xFA 0xBD

0x00FFFE10: …..

I then read out from the ECU via a LIN bus UDS command the following register values:

MMCEC 00

FSTAT 90 (CCIF: 1 FPVIOL: 1)

FERSTAT 00

FPROT 7F

DFPROT 0F

DFPROT init ? - Trrying to read out the DFPROT initialisation value from the Flash Configuration Field leads to a reset of the ECU - why?

Case 2, Flash Configuration Field with Security enabled, DFPROT init value set to 0xFF:

0x00FFFE00: 0x01 0x23 0x45 0x67 0x89 0xAB 0xCD 0xEF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFA 0xBD

0x00FFFE10: …..

Registers:

FSTAT 80 (CCIF: 1)

FERSTAT 00

FPROT 7F

DFPROT 80

DFPROT init FF

[RadekS]

Hi Gerhard,

thank you for your investigations.

Unfortunately I am afraid that I cannot explain it fully. The Case 1 even more points to the cumulative write into the Flash Configuration Field.

From RM:

“If a double bit fault is detected while reading the P-Flash phrase containing the P-Flash protection byte during the reset sequence, the FPOPEN bit will be cleared and remaining bits in the FPROT register will be set to leave the P-Flash memory fully protected.”

And

“If a double bit fault is detected while reading the P-Flash phrase containing the EEPROM protection byte during the reset sequence, the DPOPEN bit will be cleared and DPS bits will be set to leave the EEPROM memory fully protected.”

That exactly explains Case 1:

1. FPROT 7F and DFPROT 0F are configured exactly per description above.
2. Trying to read out the DFPROT initialization value from the Flash Configuration Field leads to double bit fault detection and invoking Machine Exception. It seems that MCU reset is already preprogrammed way how to leave Machine Exception service routine. The Machine Exception is not standard interrupt. The registers are not stacked on enter – therefore we cannot use RTI instruction on end.

About Case 2)

It seems that double bit fault was not detected in the Case 2, but the FPROT 7F and DFPROT 80 are obviously incorrect values.

Even automatic single bit error fix cannot explain difference between DFPROT register value and DFPROT init value in the Flash Configuration Field (difference in 7 bits). So, it seems that DFPROT register value is somehow modified by your code.

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gerhardgrasruck]

Hello Radek,

we have found the solution. We use, as I have already written, the CodeWarrior flash functionality (via PE Mulitlink or Cyclone Pro Debug interfaces). to flash the image to the ECU. However, if the image is flashed directly with the Cyclone Pro without participation of the CodeWarrior, everything works fine even with Security enabled. It seems that the CodeWarrior changes something when flashing, but we have no clue what that could be.

[RadekS · Accepted solution]

Hello Gerhard,

It looks like some issue in CW download configuration.

If you use Flash Programmer Task for MCU programming, please:

1. ensure that you checked “Do not unsecure” check box in erase action. That will manage, that Flash Configuration Field stay in erased state prior programming.

2. ensure that Debugger will perform either Standard Download or download through Flash Programmer Task – not both simultaneously.

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[gerhardgrasruck]

Hello Radek,

sorry for answering late, but there were other pressing issues and we could only now spare some time to revisit this issue.

We have tried out your suggestions and removed additional steps from the Code Warrior flash sequence, which fixed the problem.

So, the issue may be considered fully resolved.

Many thanks for your help,
Gerhard

[RadekS]

Hello Gerhard,

Thank you very much for notification.

I am very glad that it works correctly now.

Have a great day,
Radek

[RadekS]

Hi Gerhard,

Unfortunately, I don’t have any experience with using Vector vFlash bootloader.

However, from your description is clear that problem is in the cumulative programming of the same phrase. The Flash has ECC – flash write command will write also ECC checksum. When you will rewrite the same data with a different value, the generated ECC will be also different. Since programming may change bit cells only in the direction from log1 to log0, the result ECC value will probably not fit to even to any of used data values. The result of such cumulative write may be:

1. No error

2. Single bit ECC checksum error

3. Double bit ECC checksum error

The resulting behavior depends on specific bit combination. So, the behavior is almost unpredictable. Additionally, in the case of Single bit ECC checksum error, the ECC state machine will fix damaged bit (probably not correct one).

The flash phase must be erased prior programming.

So, if that phrase already contains any data, we must read the whole sector, modify target data, erase the whole sector and program it again.

I am not sure whether Vector vFlash bootloader contains such feature.

Idea: I suppose, that the last P-Flash sector with security byte and reset vector is already occupied by the bootloader.

Is it possible to secure MCU directly in bootloader code?

I hope it helps you.

Have a great day,
Radek

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------