TMS320F2800157: TMS320F2800157

Hi Samuel,

1.

I believe the following requirement from the Secure Boot app note only applies if using the secure flash boot mode:

"Use the LOCATION pragma to specify the address within the intended authentication range for the CMAC golden tag. For CPU1/CPU2, this address must be the entry address + 2 and for CM, this address must be the entry address + 4."

Since you are calling the calculateCMAC API directly, you can specify where the tag is located:

applicationCMACStatus = CPU1BROM_calculateCMAC (CMAC_AUTH_START_ADDRESS, CMAC_AUTH_END_ADDRESS, CMAC_AUTH_TAG_ADDRESS);

The bootROM's secure flash boot function calls this API with hard-coded parameters that are not modifiable so it does not know where you've placed the tag, hence why the app note instructs you to place it at predefined addresses using the LOCATION pragma depending on which secure flash boot mode you've selected.

2.

Did you get a timeout error due to the interrupt:

3.

Since this is a secure ROM function I don't have access to the code to create a proven flowchart of how the function works, however the app note provides the following flowchart:

This flowchart is intended to reflect the calculateCMAC function. It is applicable to both the secure flash boot function and the calculateCMAC API.

Let me know if you have additional questions.

Thank you,

Luke

Hello Luke：

Thank you for your reply.

1. As we know, we can specify where the tag is located if we did not use security flash boot mode. how calculate the CMAC if CMAC within authentication area, and how calculate the CMAC if the CMAC out of authentication area?

2. The return value is 0xFFFFFFFF when we call CPU1BROM_calculateCMAC BootROM API, in my opinion, there is no flash erase/write operation during CPU1BROM_calculateCMAC execution, why require us disable interrupt?

3. we generate .hex file according to guide, but the .hex file is not Intel standard hex format, see bellow, so can you explain how to analyse the .hex file?

%4E62F800080000004848E8FFFFFFFFFFFFFFFFFFFFFFFF0043003A002F0057006F0072006B002F
%4E6D780008001000300031005F00500072006F006A006500630074002F00300032005F00450047
%4E6E08000800200053004D002F00300034005F0054006F0075006300680020005300420057002F
%4E60380008003000560065006E00750073002F0042006F006F0074006C006F0061006400650072
%4E606800080040002F00530065006300750072006900740079005F0042006F006F0074002F004A
%4E6C68000800500044005F00500042004C005F0046003200380030003000310035005F00560030
%4E6ED8000800600033002F00530044004B002F006400650076006900630065002F006400720069
%4E6E0800080070007600650072006C00690062002F00630061006E002E0068000000000043003A
%4E6FA800080080002F0057006F0072006B002F00300031005F00500072006F006A006500630074

Hi Samuel,

1. I've asked one of our Boot-ROM experts to clarify this

2. From my reading of our specs on the secure ROM functions, if an interrupt occurs during execution of a secure ROM function, a reset will occur. Can you probe the XRSn pin to verify that a reset is not occurring? Is the return value always 0xFFFFFFFF or do you get a different result when interrupts are disabled?

3. I'll discuss this with our hex utility expert to see if there is another way to view the .hex file.

Thank you,

Luke

Hello Luke:

I have another question for security boot, this MCU need about 400ms to authenticate first 16K area in security boot mode, I think the time is very long, maybe it is not feasible for automotive requirement since customer require us sending first CAN data within 150ms after power on, so do you have another solution or sugestion except chaning MCU?

thank you.

/BR

Samuel

Hi Samuel,

You're not using Secure Flash boot mode right? Just using the calculateCMAC API? If so I think the timing would be closer to 20 ms since the algorithm would run off of the PLL. What is the customer's SYSCLK frequency?

Thank you,

Luke

Hello Luke:

Reply as bellow:

From my reading of our specs on the secure ROM functions, if an interrupt occurs during execution of a secure ROM function, a reset will occur. Can you probe the XRSn pin to verify that a reset is not occurring? Is the return value always 0xFFFFFFFF or do you get a different result when interrupts are disabled?

I probe the XRSn pin, it keep high. but the software seemed to be restart abnormally by sending special CAN frame; 

You're not using Secure Flash boot mode right? Just using the calculateCMAC API? If so I think the timing would be closer to 20 ms since the algorithm would run off of the PLL. What is the customer's SYSCLK frequency?

We use SYSCLK frequency is 120MHz(TMS320F2800157), We not use Secure Flash boot mode and use the API interface to calculate the first 16k data(0x80000~0x84000), the time about 57ms, calculate the second 16k data(0x84000~0x88000),the time about 63.2ms. it's not consistent with 20ms by your said.

there are many question remain as bellow:

1. As we know, we can specify where the tag is located if we did not use security flash boot mode. how calculate the CMAC if CMAC within authentication area, and how calculate the CMAC if the CMAC out of authentication area?

2. we generate .hex file according to guide, but the .hex file is not Intel standard hex format, see bellow, so can you explain how to analyse the .hex file?

3. whether the API interface(CPU1BROM_calculateCMAC) can be called more than once? If we want to use this interface many times, how to implement?

4. In non-Secure Flash boot mode, whether we define the cmac_all only? Compiler can report warning if we don't define cmac_sb_1.

thank you.

/BR

Samuel

Hi Samuel,

I will be out of office today, I will respond back by tomorrow.

Thank you,

Luke

Hi Samuel,

On reset issue -

Samuel Li said:

From my reading of our specs on the secure ROM functions, if an interrupt occurs during execution of a secure ROM function, a reset will occur. Can you probe the XRSn pin to verify that a reset is not occurring? Is the return value always 0xFFFFFFFF or do you get a different result when interrupts are disabled?

This is security violation reset and does not propagates on the XRSn pin. User can check the status of SCCRESETn bit in RESC register  (Table 4-71. RESC Register Field Descriptions) to know if this reset has been asserted. 

Samuel Li said:

We use SYSCLK frequency is 120MHz(TMS320F2800157), We not use Secure Flash boot mode and use the API interface to calculate the first 16k data(0x80000~0x84000), the time about 57ms, calculate the second 16k data(0x84000~0x88000),the time about 63.2ms. it's not consistent with 20ms by your said.

As per the table you are referring, 20ms time is when CPU running at 200Mhz. This is generic table which has been provided for best case and for different CPU frq, it need to be scaled accordingly. Other factor which will impact this time will be flash wait state and from where the code is getting executed. Are you running it from flash ? 

Samuel Li said:

1. As we know, we can specify where the tag is located if we did not use security flash boot mode. how calculate the CMAC if CMAC within authentication area, and how calculate the CMAC if the CMAC out of authentication area?

We need to check with our SW team expert and will get back to you soon. 

Samuel Li said:

2. we generate .hex file according to guide, but the .hex file is not Intel standard hex format, see bellow, so can you explain how to analyse the .hex file?

Were you planning to attach something here ? Also what do you mean by "analyze the hex file" ?

Samuel Li said:

3. whether the API interface(CPU1BROM_calculateCMAC) can be called more than once? If we want to use this interface many times, how to implement?

It should be possible to call it multiple time. Are you facing any issue when you call it 2nd time ? It'll help if you can provide more detail on the issue you are facing. 

Samuel Li said:

4. In non-Secure Flash boot mode, whether we define the cmac_all only? Compiler can report warning if we don't define cmac_sb_1.

Not very clear on this query. Why do we need CMAC for non-Secure Flash Boot ? 

Regards,

Vivek Singh

Hello Vivek:

thank you for your reply.

Vivek Singh said:

On reset issue -

Samuel Li said:

From my reading of our specs on the secure ROM functions, if an interrupt occurs during execution of a secure ROM function, a reset will occur. Can you probe the XRSn pin to verify that a reset is not occurring? Is the return value always 0xFFFFFFFF or do you get a different result when interrupts are disabled?

This is security violation reset and does not propagates on the XRSn pin. User can check the status of SCCRESETn bit in RESC register  (Table 4-71. RESC Register Field Descriptions) to know if this reset has been asserted. 

we will check the status of SCCRESERn bit.

Vivek Singh said:

Samuel Li said:

We use SYSCLK frequency is 120MHz(TMS320F2800157), We not use Secure Flash boot mode and use the API interface to calculate the first 16k data(0x80000~0x84000), the time about 57ms, calculate the second 16k data(0x84000~0x88000),the time about 63.2ms. it's not consistent with 20ms by your said.

As per the table you are referring, 20ms time is when CPU running at 200Mhz. This is generic table which has been provided for best case and for different CPU frq, it need to be scaled accordingly. Other factor which will impact this time will be flash wait state and from where the code is getting executed. Are you running it from flash ? 

Yes, our software is running from flash. so as you said, it's normal we authenticate first 16K in 120MHZ.

Vivek Singh said:

Samuel Li said:

1. As we know, we can specify where the tag is located if we did not use security flash boot mode. how calculate the CMAC if CMAC within authentication area, and how calculate the CMAC if the CMAC out of authentication area?

We need to check with our SW team expert and will get back to you soon. 

OK，waiting for your response.

Vivek Singh said:

Samuel Li said:

2. we generate .hex file according to guide, but the .hex file is not Intel standard hex format, see bellow, so can you explain how to analyse the .hex file?

Were you planning to attach something here ? Also what do you mean by "analyze the hex file" ?

we need to implement a Tester to parse generated .hex file, so we want to the detail format information about the file.

Vivek Singh said:

Samuel Li said:

3. whether the API interface(CPU1BROM_calculateCMAC) can be called more than once? If we want to use this interface many times, how to implement?

It should be possible to call it multiple time. Are you facing any issue when you call it 2nd time ? It'll help if you can provide more detail on the issue you are facing. 

According to guide, we need to define only cmac_all symbol, then we can use Hex2000 to generate CMAC, so we can't use Hex2000 to generat CAMC if we want to call it multiple time.

Vivek Singh said:

Samuel Li said:

4. In non-Secure Flash boot mode, whether we define the cmac_all only? Compiler can report warning if we don't define cmac_sb_1.

Not very clear on this query. Why do we need CMAC for non-Secure Flash Boot ? 

we want to use secure flash boot mode, but authenticate first 16K need 400ms, the time is very long, so we decide to use non-secure-boot mode to authenticate 16K data.

Hey Samuel,

Yes, our software is running from flash. so as you said, it's normal we authenticate first 16K in 120MHZ.

Is the 57ms and 63.2ms timing fast enough for your application? If not, would it be possible to call the calculateCMAC API from RAM?

OK，waiting for your response.

Response from our software team:

"When they are using hex tool to generate the CMAC signature of their code below needs to be followed:

• If CMAC signature is within the area being authenticated then it should be filled with 0xFFFFFFFF before running the HEX tool. The CMAC algorithm masks the signature area with 0xFFFFFFFF before calculation. The HEX tool does not know this and computes signature with whatever is the signature locations.
• If signature is outside no issues."

we need to implement a Tester to parse generated .hex file, so we want to the detail format information about the file.

You can generate your output in intel standard format according to the hex utility guide:

According to guide, we need to define only cmac_all symbol, then we can use Hex2000 to generate CMAC, so we can't use Hex2000 to generat CAMC if we want to call it multiple time.

We will check with the SW team and get back to you on this.

We want to use secure flash boot mode, but authenticate first 16K need 400ms, the time is very long, so we decide to use non-secure-boot mode to authenticate 16K data.

Have you tested to see how long the Secure Flash boot mode takes? The 400ms value is based off of F2838x.

According to our SW expert, your code will not be secure if secure flash boot is not used since you will not have a root of trust. Are you using secure flash boot to prevent your code from being tampered with or just to ensure that the flash is programmed correctly?

Hello Luke:

Luke Jones said:

Have you tested to see how long the Secure Flash boot mode takes? The 400ms value is based off of F2838x.

According to our SW expert, your code will not be secure if secure flash boot is not used since you will not have a root of trust. Are you using secure flash boot to prevent your code from being tampered with or just to ensure that the flash is programmed correctly?

As <Secure BOOT on C2000 Device> said, In secure boot mode, CPU1 authenticate first 16KB data  on INTOSC 10MHZ, and need about 400ms, for F2800157, the INTOSC is also 10MHZ, so I think the time is similar.

we have to use non-secure boot mode since the 400ms is not satisfied customer‘s requirement(they require us send first CAN frame in 150ms),even though our code maybe tampered.

for this point, our concept as bellow, do you have suggestion or better solution?

Luke Jones said:

Is the 57ms and 63.2ms timing fast enough for your application? If not, would it be possible to call the calculateCMAC API from RAM?

Yes, the time maybe less if we place calculateCMAC API to RAM and call it, But i think this is not key block point. The size of application is more than 60KB, need more time to authenticate application.

/BR

Samuel

Hi Samuel,

For the speeds you are seeing (approximately 60 ms to authenticate 16 KB of flash), it is not possible to authenticate all 60 KB of application code within 150 ms. To meet this requirement, you would need to authenticate 16 KB of flash in 39.6 ms. Ideally it should only take 33 ms to authenticate 16 BK based on the F280015x clock frequency(120 Mhz) and the data provided in the secure boot app note.

Are you securing memory via DCSM? The purpose of the secure ROM functions is to calculate the CMAC tag on secure memories without unsecuring your code. If this is not a requirement, would it be acceptable for you to calculate a CRC on your application code instead? This may be faster than calling the calculateCMAC API.

I will try to replicate this on my side to see if I can meet the 39.6 ms requirement. 

Thank you,

Luke

Hello Luke:

Luke Jones said:

I will try to replicate this on my side to see if I can meet the 39.6 ms requirement. 

Do you have any update?

In addition, do you have more documents about security boot and security update, we can refer to it.

thank you.

/BR

Samuel

Hi Samuel,

Not yet unfortunately, I have been very busy with other customer issues. I'll get back to you before the end of this week.

Thank you,

Luke

Hi Samuel,

Apologies for the delay, I will get back to you this week with my test results.

Thank you,

Luke

Hi Samuel,

I am still looking into this issue, will respond back once I'm able to successfully test this.

Thank you,

Luke

looking forward to your response.

/BR

Samuel

Hi Samuel,

I will be out of office until end of June, I'll test this after I return.

Thank you,

Luke