TMS320F28388D: secure boot update via SCI

Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Using C2000ware 05.05.01

controlCard for F28388D

I can run the example boot_ex_1_cpu1_cpu2_cm_secure_flash_cpu1/cpu2/cm successfully with secure boot emulation and default key 0xfff...

I can run the example flash_kernel_c28x_dual_ex1_c28x1 successfully and interface it with the serial_flash_programmer.exe. I can successfully flash the example led_ex1_c28x_dual_blinky_cpu1.

Now I want to use the example flash kernel with serial_flash_programmer.exe and write the secure boot example. However after starting the option 1-DFU CPU1 in the  I get a error message:

...
Bit rate /s of transfer was: 7055.239746
Application load successful!
Done waiting for application to download and boot...
SUCCESS of Command
ERROR Status: PROGRAM_ERROR
ERROR Address: 0x80002
Flash API Error: Incorrect Data Buffer Length
Please refer to the Flash API documentation for further explanation of the error.
FMSTAT Register contents: 00

I added following options to the C2000 Hex Utility to the secure boot example prior flashing it:

Enabled "Select boot mode (--boot)

Enabled table source as SCI-A port, 8-bit mode (-sci8)

Set output format to ASCII hex (--ascii)

I played around with some of theese options but I cannot flash the secure boot example. The error message above is the furthest I could get. What am I missing?

 

  • Typo: Using C2000ware v5.05.00.00 

  • Hello,

    Since the Golden CMAC Tag is allocated for 0x80002 with a size of 8 words, this can cause flash alignment issues during programming. You will have to use a post-processing script to merge the unaligned sections, I will share this with you in E2E DMs.

    Best,

    Matt 

  • Thanks Matt for helping resolve this issue.

    Just to restate the issue for clarity; since the CMAC tag starts at a non 128-bit aligned address, and then gets passed as a unique section in the UART.hex file; the Flash API rejects this as an invalid address. 

  • This is great to hear. I already thought of debugging and either changing the kernel or the hex. However I'm certain that somebody might already have run into this issue and there must be a solution. I'm really looking forward to you post processing scripts.

  • Hi Simeon,

    Please accept my friendship request on E2E, only then I can DM you.

    Best,

    Matt

  • Thanks, however I'm not sure if I'm using it correctly or maybe the use-case is different.

    1. C2000ware example project boot_ex_1_cpu1_cpu2_cm_secure_flash_cpu1

    2. It comes pre-configured with a hex2000 configuration that runs:

    "C:/ti/ccs1281/ccs/tools/compiler/ti-cgt-c2000_22.6.1.LTS/bin/hex2000" ^
    --cmac="C:/.../boot_ex1_user_cmac_key.txt" ^
    --image --memwidth=16 --romwidth=16 "C:/...\boot_ex1_flash_hex_lnk_cpu1.cmd" ^
    --diag_wrap=off ^
    -o "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1.hex" ^
    "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1.out" 

    3. To create the hex file for flashing the parameters --ascii -sci8 -boot are required, such as:

    "C:/ti/ccs1281/ccs/tools/compiler/ti-cgt-c2000_22.6.1.LTS/bin/hex2000" ^
    --cmac="C:/.../boot_ex1_user_cmac_key.txt" ^
    --image --memwidth=16 --romwidth=16 "C:/...\boot_ex1_flash_hex_lnk_cpu1.cmd" ^
    --diag_wrap=off ^
    --ascii --boot -sci8 ^
    -o "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1.hex" ^
    "boot_ex1_cpu1_cpu2_cm_secure_flash_cpu1.out" 

    4. This does not work because from the Assembly Language Tools : "To boot from a SPI-A port, specify --spi8 when invoking the utility. Do not specify --memwidth or --romwidth."

    Merging missaligned blocks (merge_misaligned_blocks.py) fails:

    ValueError: invalid literal for int() with base 16: '%4E6F38000801A0FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF%4E6F2800080190FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF%4E6F58000801C0FFFFFFFFFFFFFFFFFFFFFFFFFF

    As the readme states: it is intended to align configuration of otp registers. However I'm not writing any otp register; I try to flash a secure boot signed image via SCI.

    My goal is maybe too obvious to me, but I might be spoiled:

    * put a SBL + bootloader into Zone 1

    * SBL verifies Zone 2

    * On demand (eg. SCI/CAN command) SBL copies a flash kernel to RAM, runs it

    * flash kernel unlocks Zone 2, writes update

    Of course Zone 1 and Zone 2 are signed and verified with the CMACKEY. Also JTAG is locked.

    Is this (DFU/OTA) actually supported with secure boot? I read spract3, sprabv4i, sprujh3, spracp8a, spruii0f etc. All the bits are there, but not merged together.

  • I just found 

    C:\ti\C2000Ware_5_05_00_00\utilities\flash_programmers\cmac_preprocessing

    It helps aligning the ascii hex output that was generated with the conflicting parameters -romwidth 16 -ramwidth 16 ... -boot -sci8

    merge_cmac.py successfully merges the golden cmac at address 08 00 02. However it is missing custom range support for the cmac_all at 08 70 02 location.

    I modified merge_cmac.py to inject a custom codestart_addr if it could not be found as dedicated block:


    def move_cmac(blocks, cmac_addr, codestart_addr):
        if cmac_addr not in blocks:
            print("CMAC address", cmac_addr, "is not a valid block")
            exit(2)
        if codestart_addr not in blocks:
            print("Codestart address", codestart_addr, "is not a valid block, will add it with length 2 (4 bytes of FF)")
            blocks[codestart_addr]['length'] = 2
            blocks[codestart_addr]['data'] = ["FF", "FF", "FF", "FF"]

    This is performed in addition to the normal merge and when an additional cmac_addr and codestart_addr is given.

    There is no error checking and what not, but I could finally flash a secure boot image via SCI and verify the custom range with the secure ROM api.

    Thanks for your support!