Post Go back to editing

Fail to UARTFlashProgrammer for ADSP-CM40x 2.0

We have successfully written our hex code to the development board. (but that was a <rev2.0).

Now working on our own test board (with >rev2.0) we have trouble on flashing the code.

Running from IAR, all goes well. We can debug the code an when rebooting the board, the program is started from flash and working.

Security headers are enabled.

EccGen has run.

results:

#define ADI_SECURITY_SIGNATURE0 0x16c80dbd
#define ADI_SECURITY_RESERVED0  0xffffffff
#define ADI_SECURITY_USER_KEY0  0xa4b8e4a0
#define ADI_SECURITY_USER_KEY1  0xd2041dd7
#define ADI_SECURITY_USER_KEY2  0x18839df8
#define ADI_SECURITY_USER_KEY3  0x8392c1fe
#define ADI_SECURITY_BOOT_FLAGS 0x00000000
#define ADI_SECURITY_IVT_ADDRESS 0x18001000
#define ADI_SECURITY_ECC0       0x138a6fc7
#define ADI_SECURITY_ECC1       0xffffffc2
#define ADI_SECURITY_SIGNATURE1 0xa4287f8a
#define ADI_SECURITY_SIGNATURE2 0x14b234f2

Next things we see:

Steps we do:

- select bootmode 3

- power up the board

- run UARTFlashProgrammer

- result: FAILING TO PROGRAM

We can make the programming to work, if we first erase the flash and don't specify the security key.

Steps we do:

- select bootmode 3

- power up the board

- run UARTFlashProgrammer

- first select Erase flash

- result:

- now wait at least 60 seconds (very important, because this is the amount of time that is actually needed to erase the flash)

- after that, reboot the board (still bootmode 3)

- then program the flash

- result: FAILING TO BOOT

- as you can see, the flash is completed, but rebooting the board in mode 1, we see no activity so we think our code is not running.

What could be wrong?

1. Why is the direct flashing not working? Why must we do a full erase before we can flash our code?

2. Why doe our code not start after flashing (without security key)?

  • Hi Francis,

    I suspect that while you are trying to load the code, which changes the security header with keys as a0e4b8a4d71d04d2f89d8318fec19283, the flash has default keys that time. That means there is a mismatch in the key that you sent over the UART WSD utility and the key which is programmed in the flash. Regarding your code not able to boot, I suspect your code has some printf statements thus causing it not to boot.

    So we could proceed with a step by step approach.

    1. Put to BMODE=3, Erase the flash and wait for 60seconds and press reset
    2. Program the flash, with Button_LED_GPIO_CM408F_2.0 present in this folder <ADSP-CM40x\CM403F_CM408F_EZ-KIT\tool\UARTFlashProgrammer> with the key field of GUI left blank.
    3. Switch to BMODE=1, press reset and press push buttons on the board and led will glow.
    4. In case you have custom board try to load a simple led blink code. (replacement for steps 2,3) with key field of GUI blank. When you build the led blink code to generate hex file, make sure that the security header is the default one programmed in the adi_ecc.h file. Switch to BMODE=1 and check if the application is booting.
    5. Now if you want to change the keys to a0e4b8a4d71d04d2f89d8318fec19283. Build the simple led blink code with new values of key in adi_ecc.h file and run ECC gen.exe; generate a hex file out of this.
    6. In case you are using EZ-KIT you could generate hex file of Button_LED_GPIO example by changing the key to a new one in adi_ecc.h and running ECC gen.exe. Make sure you remove the printf statements by changing this line #define DEBUG_PRINT (0) in the example code. ( this is replacement for step 5)
    7. Put back to BMODE=3 and program the flash with the key field blank and load the hex file generated by step 5 or 6. The key field is kept blank because the flash is programmed with default keys already and it does not have new keys yet. Flash security header with default keys does not require keys to be sent over UART.
    8. It should be successfully flashed and the flash header is now programmed with new keys. After this to carry out further flashing, it is required to set the key field as a0e4b8a4d71d04d2f89d8318fec19283 because the flash security header is now programmed with this.

    Regards,

    Kritika

  • Tried it, but no luck.

    Steps I did:

    1. change the key in adi_ecc.h.

    2. ran ECC gen.exe (adi_ecc.h was changed with new values for some defines)

    3. build my code again (with Semihosted off, and with all printf's removed)

    4. erased the flash (mode 3)

    5. wait 60 seconds

    6. reboot (mode 3)

    7. flash the hex file (mode 3) with blank key field

    8. reboot (mode 1)

    nothing

    The first thing I do in my code (main()) is setting a LED. But I don't reach that part.

    But when I try to flash the same program again, but now with the key field set, the flashing won't work.

    So in my opinion, there is something with the security key part.

    If the program is flashed with the new key, I also can't connect with my J-Link probe (after manually changing the .jlinkscript to the new key).

    Also when I try to program the a "default key" hex, I only can do that after I erase the flash. So when that "default key" hex file is programmed, I can't program it a second time without first erasing the flash.

    Another thing:

    If I erase the flash, run the code (with "custom key") once from the debugger and then startup the board standalone (disconnecting all cables except the power) then the board starts just file.

  • Hi There is a known issue with the UART Boot Loader on BSP> 2.0. We are working to fix it in the next release.

  • This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

    Thank you,
    EZ Admin