TMS320F28388D: F28388D Safe USB boot design

John,

The above flow will work, for #3 we need to get the format in binary and save as .dat below is hex utility directive we need to invoke:

"hex2000.exe -boot -b F28x7x_Loader_Test.out -o Loader_Test_Converted.dat" (from example.txt in C:\ti\c2000\C2000Ware_5_02_00_00\utilities\flash_programmers\usb_flash_programmer\)

In the Secure flash example, all you should need to do is set the output mode to binary as well as enable the -boot switch, the rest should be correct. 

If you right click on the project and select "properties" it will bring up the below dialogue, navigate to the C2000 Hex utility and then the following screens to get the -boot

then here to set the output mode to binary - b

You can choose to rename the file extension from .bin to .dat, I'm not really sure that matters

This file can be passed to the USB bootloader program mentioned in the above directory.

One last point, early in your post you mention however, it seems with the native USB boot loader on the F28338D we can't use CSM as the boot loader is hardcoded.  

This statement is correct, but I'm curious if your experience on a previous C2000 device is different, or was this coming from a different MCU.

Best,

Matthew 

Hello MatthewPate,

Thank you for the confirmation, I'm now working on this idea right now, I believe in 1 week or 2 I should be able to test it and confirm here if it works or if there are any issues.

Regarding CSM, yes, we used to use F28069 with CSM, but for that DSP the USB boot loader was different and the source code was available, but in F28388 the story is more complicated.

Thanks

John

John,

Thanks for the background, will look for your reply if you need anything.

Best,

Matthew

Hello MatthewPate ,

Following our previous discussion, I started to use example code "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1" for the 1st step, I've commented the sections related to CPU2 and CM as I want it to only work for CPU1, however, no matter what I do, the code gets stuck in the forever loop ( D1 remains ON, on the Control Card), obviously the Authentication doesn't pass and "CPU1BROM_calculateCMAC" returns 0xFFFFFFFF , so below is what I've done:

1. I commented on the sections for CPU2 and CM:
   
2. I followed the document  SPRACT3 , in the document it briefly says the used Zone1 sectors should be EXEONLY, I also saw this solution offered Here.
3. Following the thread above, I went to "dcsm_security_tool" and selected the sector0 and sector 1 as EXEONLY, thus I got the following values for ZONE1:
   
   
4. I went to UNIFLASH and programmed these values for ZONE1
   
5. Now going back to "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1" I've built the example and got the .hex file.
6. going back to UniFlash I've directly flashed the .hex file into the DSP ( this takes much longer time than writing a .out file)
   
   
7. Now Back to CCS and the "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1" , I have to disable Erase flash from the settings as I don't want the CCS puts back the .out again into the DSP ( this is not mentioned in the guides of TI, but it clearly states .hex file must be in the DSP and not .out)
   
   
8. Now I follow the guides, which states Disconnect and reconnect to CPU1:
   
   
9. I get the following error in the meantime, but I continue regardless
   
   
10. Now I put the values for 0xD00,0xD01 and 0xD04 per application request
    
    
11. Now I reset the DSP per guides:
    
    
12. After reset I see the following
    
    
13. Now I press resume:
    
    

After this the D1 stays fully ON and doesn't blink.

My other observations:

- One time by luck, the code passed the Authentication and the led started to blink, but I can't recreate the situation

Please advise how to proceed and if any of the above steps has to be changed.

John

Hello MatthewPate ,

Just checking on this matter, could you have a look on this issue? we are a bit tight on timing to deliver this task.

thank you for your time.

John

John,

Apologies for the delay on my part, I'll check up on this thread more often.  When you are building the example for the above run with CCS/JTAG, did you keep the hex2000 settings as is in the example, this would be needed since we are loading the image from CCS vs USB.  Just want to confirm we haven't made those changes yet.

Regarding the DCSM/EXE only; are there any constants stored in the flash regions or any reason some other part of your code would be trying to access the contents of that region?  Only for the sections that have code only do we want to turn on the EXE only protection, all data reads will be blocked from those areas.

One thing we could do is increment the link pointer, which will reset all the DCSM features to their native erased state, which will turn off the EXE only to see if this is the issue.

Best,

Matthew

Hello @MatthewPate, 

Sorry, I've been traveling this week to the customers...

MatthewPate said:

Apologies for the delay on my part, I'll check up on this thread more often.  When you are building the example for the above run with CCS/JTAG, did you keep the hex2000 settings as is in the example, this would be needed since we are loading the image from CCS vs USB.  Just want to confirm we haven't made those changes yet.

I'm running purely the TI example code, so no changes at all, as mentioned only a small portion of the code is commented, no other changes in the compiler.

MatthewPate said:

Regarding the DCSM/EXE only; are there any constants stored in the flash regions or any reason some other part of your code would be trying to access the contents of that region?  Only for the sections that have code only do we want to turn on the EXE only protection, all data reads will be blocked from those areas.

As I'm running the example code of TI, I believe there should be no issue there.

MatthewPate said:

One thing we could do is increment the link pointer, which will reset all the DCSM features to their native erased state, which will turn off the EXE only to see if this is the issue.

Can you please explain how this is done? -- Is this necessary to be done on the example code as well? a bit confused here.

Thank you in advance for your help.

John

Hi John,

Can you confirm you did not modify the CMACKEY value in user otp? It's possible this may been done when enabling EXEONLY in SysConfig.

Thank you,

Luke

Hello Luke,

Absolutely not, No change in any settings within the example, CMACKEY is untouched, the only change as mentioned above is commenting on the codes for CPU2 and CM.

The behavior was exactly the same when I was running the example without changing the EXEONLY in Sysconfig. ( How this can be an issue?)

There is only one difference, I've changed the Clock on my control card to 20MHz ( by replacing the respective resistor) , so I had to add the following Macro, can this affect anything? 

John

Hello Luke Jones,

Is it possible for you to check this out at your end? just to make sure if there is any bug with the code once the clock is set at 20Mhz or if this is totally a different issue -- we are running out of time for understanding the cause.

Thank you for that.

John

Hi John,

I will be out of office tomorrow but return on Tuesday. I have another idea what could be the cause of this issue.

Did you program custom CSM passwords along with enabling EXEONLY? If so, this will cause data reads and writes to be blocked in the EXEONLY sections unless the DCSM is unlocked after each device reset. This could cause the USB programmer to program nothing in the code regions that have EXEONLY protection, resulting in the CMAC authentication failing.

Would you be able to test this without exeonly protection by updating your linkpointer? This will restore the settings in the zone select block to their defaults and disable EXEONLY.

Thank you,

Luke

Hi Luke Jones ,

Luke Jones said:

Did you program custom CSM passwords along with enabling EXEONLY?

I'm using the default CSM password, so no changes there yet.

Luke Jones said:

Would you be able to test this without exeonly protection by updating your linkpointer? This will restore the settings in the zone select block to their defaults and disable EXEONLY.

Can you please let me know how should I do this?

John

Hi John,

Since you are using default CSM passwords the EXEONLY setting is not applicable, no need to change this.

Can you confirm that boot_ex1_flash_hex_lnk_cpu1.cmd matches the values for 

#define CMAC_AUTH_START_ADDRESS
#define CMAC_AUTH_END_ADDRESS
#define CMAC_AUTH_TAG_ADDRESS

in your main .c file?

Could you try testing this without USB loading? In other words, could you test simply uploading the application code to the device via JTAG and then performing the EMU boot configuration to attempt secure boot? It's possible that the USB bootloader is modifying the application in some what when it programs the flash that differs from the application code when uploading via JTAG directly. You should be able to do secure boot successfully if only using JTAG to upload the application code. I can try this on my end as well to confirm.

Thank you,

Luke