This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

UNIFLASH: Verify Fails When Loading 2 Binaries and Locking Flash Sector

Part Number: UNIFLASH


Hello,

I am using the command-line tool of dslite to load binaries to my products (Using CC1312). I generated a standalone .ufsettings file from uniflash to perform a flash sector lock as well.

When I load 2 binaries (firmware generated by CCS and a separate data structure at a dedicated address in memory) and lock a memory sector, the binaries load just fine, but the -v flag causes the tool to fail.

This is the tail of the output from dslite:

Verifying Program: /Users/---/////Firmware.out
Preparing ...
PT_LOAD[0]: 0 of 101295 at 0x0
PT_LOAD[0]: 32752 of 101295 at 0x0: 31%
PT_LOAD[0]: 65504 of 101295 at 0x0: 63%
PT_LOAD[0]: 98256 of 101295 at 0x0: 95%
PT_LOAD[5]: 0 of 1292 at 0x18bb0: 98%
PT_LOAD[1]: 4 of 8 at 0x190bc: 99%
PT_LOAD[2]: 0 of 88 at 0x57fa8: 99%
error: Cortex_M4_0: File Loader: Verification failed: Values at address 0x00057FF2 do not match Please verify target memory and memory map.
Finished: 99%
Failed: File: /Users/---/////Firmware.out: a data verification error occurred, file load failed.

It looks to me like the memory at address 0x00057FF2 is mirroring the content of the CCFG flash sector locks, but I cannot verify from the Reference Manual.

Why does verify look at this address range? It out of range for the firmware and the data structure binary so I don't know why that's being checked.

Is there a way to still verify my binaries are downloaded correctly and that the sector is locked in a single dslite command?

I can verify the 2 binaries without the .ufsettings file but when that gets reintroduced this failure comes back. With the Uniflash standalone tool (which is not something I can deploy) I see that an added flag of

-s VerifyAfterProgramLoad=\"No verification\"

is added without my selection. I'm curious if this is TI's workaround for a problem like this...

-Seth