S32k144 Program Partion command (in S32k Reference manual v14 addendum)

[woolim]

While reviewing the latest S32K14x Reference Manual, I noticed the Program Partition command table was updated to include two additional bytes:

• FCCOB[6] – BKRON (Boot Key Restriction On, only bit 0 used):
  0 = Keys with boot protection enabled are accessible when Secure Boot is not enabled
  1 = Keys with boot protection enabled are not accessible when Secure Boot is not enabled or Secure Boot failed.

• FCCOB[7] – Minimum MAC Length for CMD_VERIFY_MAC:
  0x0 = 128 bits; 0x1..0x7F = 1..127 bits.

Our current production flow (S32K144, SDK 4.0.3) executes the Program Partition command using FCCOB0..5 only (FlexRAM load option, EEE data set size code, FlexNVM partition code, etc.). We do not explicitly write FCCOB[6] or FCCOB[7], and the devices operate as expected.

Could you please clarify the following?

1. Are FCCOB[6] and FCCOB[7] mandatory for S32K144? If the command is issued without writing these bytes, what default values (if any) are used internally, and is that behavior defined/guaranteed?

2. If they are optional, what values does NXP recommend for applications that:

   • do not enable Secure Boot or use CSEc boot-protected keys, and

   • do not plan to use CMD_VERIFY_MAC?
     (Is it safe to explicitly program BKRON = 0 and Min MAC Length = 0x00 (128-bit), or should these be left unspecified?)

3. Backward compatibility: For units already partitioned in the field (where FCCOB[6]/[7] were not written), is any re-partitioning or re-programming required to align with the updated definition?

4. For FCCOB[6], when the manual says “only bit 0 used,” should bits [7:1] be written as 0 for forward compatibility, and what happens if any are non-zero?

5. Are there any errata or revision notes explaining the addition of these two FCCOB bytes to the Program Partition command?

Environment:

• Device: S32K144 (FTFC)

• SDK/driver: S32K1 SDK 4.0.3

• Secure Boot / CSEc: not enabled

• Reference: see attached screenshot from the latest RM showing the new FCCOB[6] and FCCOB[7] fields.

Thank you for the guidance. I can share our exact FCCOB write sequence if needed.

[lukaszadrapa]

Hi @woolim 

Updated CSEc firmware is designed in a way that it is backward compatible.

There’s no problem if you do not enable CSEc. The content of FCCOB[6] and FCCOB[7] will be ignored when CSEc key size is 0. You wrote that “Secure Boot / CSEc: not enabled”, so it does not affect your application.

There could be a problem when CSEc is enabled. I checked the drivers in SDK 4.0.3 and it’s not so straightforward. The problem is that FCCOB registers are automatically cleared only after reset. When FCCOB registers are used to launch flash operations, the content either remains the same or some registers are used to return some values. But when you want to initialize the registers for another operation, the content is not cleared automatically. And the key point – the driver don’t do that to. The driver just writes required registers for given operation and the rest is untouched. Normally unused FCCOB registers are ignored by flash state machine. But because new functionality was added to Program Partition program, this could cause some issues. In this case, it would be necessary to check what is the real content of FCCOB registers when launching Program Partition command. If it is first flash operation after reset, there’s no problem. If there are some remains from previous operation, yes, that could be a problem.

Regards,

Lukas