CCS/TMS320F280041: Flashing via Uniflash and JTAG gives a "memory map prevents reading @ 0x88000" error

Chris,

in the meanwhile I had the chance to try an align(4) version. But that makes no difference for my problem.

But I made another interesting discovery: Using CCS (V.8.3.0) and flashing the code using CCSs AutoEcc-generation I got ECCs different of what I should become I think. But only for 2 bytes within the first few words. And I can't find any reason for that.

I build my project and flashed it via CCS with AutoEcc generation and build the project another time with linker generated ECC and split the Ecc-Section into separate file using the ROMS cmd.

It starts with the following section (linked @ 0x82000):

:020000040108F1
:2004000058F8C967AFE436517720F8643FAA77C7DF37E0759B792FDFF87C60D9DB524AD4A3

Do you have any idea why that could occur?

Besides: Flashing the out-file that contains the linker generated ECCs does work for my bootloader to compare for the correct ECCs successfully but gives an error msg like:

.ecc0: 0 of 64 at 0x1080000: 97%
error: C28xx_CPU1: File Loader: Verification failed: Attempted to write past the
 end of memory at 0x1080000@Program
        Finished: 97%

All read out via CCS:

The disassembled code itself:

The code-mem read out:

The CC read out: the red marked bytes are different to the bytes within the separately generated ECC-File.

Marco,

1.  
If you want UniFlash to program ECC for the entire Flash image (including holes), you can use fill in your linker command file to fill the holes with 1s.  By doing this, UniFlash's AutoEccGeneration will calculate ECC for the entire Flash image assuming all 1s data for any unfilled locations.

2.
When you use linker generated ECC, you need to make sure you provide the vfill value as 1s, if not linker will assume the unfilled locations as 0s when calculating ECC.

3.
ECC generated from AutoEccGeneration option vs Linker should be same if the input 64-bit data and the address given are same for both methods.  However, you cannot compare ECC of un-programmed locations (left as erased) to that of locations for which you program ECC assuming all 1s data.  Please check if you are comparing ECC of unprogrammed locations with that of all 1s data.  

4.
Regarding the error "Attempted to write past the end of memory at 0x1080000@Program", compiler team made some changes recently to the Linker-generated ECC feature.  Not sure if there is any bug in it.  I am sorry to mention that we can not try that for you until mid-February.  

However, for your situation, I don't think you need to use linker-generated ECC.  When loading Flash image via UniFlash, enable AutoEccGeneration and when programming Flash via your custom boot loader, use Fapi_AutoEccGeneration programming mode.  In the ECC correctness check that you are doing, make sure you check ECC only for the locations that you really programmed.  You can accomplish this by avoiding the ECC-check when all the 64-bits of data is 1s.

Hope this helps.

Please let me know if I misunderstood any of your requirements or findings.
Also, note that the images that you shared are not visible for us.

Thanks and regards,
Vamsi

Vamsi,

thank you for your quick and detailed response.

1. I tried that and it works fine but I prefer 2.

2. That works as well fine for me.

3. You are absolutely correct, I wrongly compared 16bit words with Ecc values but it is only 8bits for each 64 bit of code. The "workarround" you suggested (make sure you check ECC only for the locations that you really programmed.  You can accomplish this by avoiding the ECC-check when all the 64-bits of data is 1s) works fine for me.

4. For the error msg issued from uniflash ("Attempted to write past the end of memory at 0x1080000@Program") I will wait for the next releases, that does not prevent me from doing progress within my project.

Once again thanks a lot for your help.

Thanks and regards,

Marco