CCS/TM4C1294NCPDT: Data verification error, file load failed

HI,

 Sorry to hear your problem. Can you try a few things?

  - Do you see the same problem on a different computer?

  - Can you try a different JTAG cable?

  - What debug probe do you use? Do you have another one to try?

  - Can you do a "unlock" operation? The unlock is a mass erase operation.

  - Can you check your board and make sure there is no loose solder connection on any components?

  - What is your RBIAS pin connection? A RBIAS resistor is required even if the application does not require the Ethernet PHY. In this case, a 4.7KOhm 10% tolerance resistor can be used in place of 4.87KOhm 1% tolerance resistor between the RBIAS pin and GND.

 - If you use Ethernet, do you have proper protection diodes on the Ethernet signals? Without the protection diodes there is a chance of device damage.

Hi Charles,

1. Yes I did encounter this with another laptop a while back and I don't know what fixed it. This is the 2nd Laptop.

2. I did try with a different JTAG. Not just the cable but whole thing.

3. I'm using Tiva TM4C1294XL Launchpad debug probe. And I did try on a different one and I'm encountering same issue. 

4. I tried it but I don't think it made any difference.

5. I tried on couple of boards and I'm getting the same issue.

6. My board has Ethernet and we have protection diodes on them.

I have observed that when I try to write to FLASH the debugger goes to boot_cortex_m.c file and is stuck in this function

__attribute__((section(".text:_c_int00_noargs"), used, naked))
void _c_int00_noargs(void)
{
_c_int00_template(0, 1);
}

and when I try to reflash it then I receive this error

CORTEX_M4_0: Flash Programmer: Flash programming timed out.
CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.
CORTEX_M4_0: GEL: File: C:\Users\drai\Documents\Repos\PoE_Digital\ats-poeclock\Debug\ats-poeclock.out: a data verification error occurred, file load failed.

And I have no idea what the reason is. My code was working at 1 PM and I tried to reflash it at 4 PM and this issue started. and I didnt make any change in my code.

Regards,

Deepak

Hi,

Deepak Rai said:

1. Yes I did encounter this with another laptop a while back and I don't know what fixed it. This is the 2nd Laptop.

So this is not a computer dependent.

Deepak Rai said:

2. I did try with a different JTAG. Not just the cable but whole thing.

The jtag cable can be ruled out.

Deepak Rai said:

3. I'm using Tiva TM4C1294XL Launchpad debug probe. And I did try on a different one and I'm encountering same issue. 

What do you mean you  try a different one. A different custom board you built or a different LaunchPad you are using as a debug probe. If you are using the same launchPad then it is likely something to do with the launchPad. I will never recommend people use the launchPad as a debug probe to debug out to the target system with blue wires. You should really own a real debug probe of you own instead of using a launchPad as described in the apps note to debug out another board.

Deepak Rai said:

4. I tried it but I don't think it made any difference.

Ok, the device may seem fine. 

Deepak Rai said:

5. I tried on couple of boards and I'm getting the same issue.

As I suspected from #3, it may be the launchPad that you use as a debug probe that is an issue. If the JTAG connection and anything that is related to debug (e.g. the ICDI on the launchPad) then it will have problem with any boards you have.

Deepak Rai said:

6. My board has Ethernet and we have protection diodes on them.

good that you have the protection diode. Make sure you have the RBIAS taken care too.

With everything said, I will suggest you use a real debug probe like XDS100, XDS200 or JLink. 

HI Charles,

I have tried 3 different launchpad boards to debug and both are giving me the same error. And yes, I'll try a real debug probe but I don't think that is the issue since I tried 3 different ones. And also on multiple custom boards.

Do you have any thoughts on this?

I have observed that when I try to write to FLASH the debugger goes to boot_cortex_m.c file and is stuck in this function

__attribute__((section(".text:_c_int00_noargs"), used, naked))
void _c_int00_noargs(void)
{
_c_int00_template(0, 1);
}

and when I try to reflash it then I receive this error

CORTEX_M4_0: Flash Programmer: Flash programming timed out.
CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.
CORTEX_M4_0: GEL: File: C:\Users\drai\Documents\Repos\PoE_Digital\ats-poeclock\Debug\ats-poeclock.out: a data verification error occurred, file load failed.

Also, the custom board that we have had TM4C1294KCPDT and we wanted to increase the flash and we switched to TM4C1294NCPDT.

And this new MCU is the one that I have seen this issue recently. Can the issue be related to something with the change? I have verified the targetConfig file and GEL files as well.

Regards,

Deepak

Can you even connect to the target? Or you only have the programming problem but connecting to the target is ok?

Charles,

I am able to program but in my code I need to save some values in Flash memory and that's when I see these events.

I have observed that when I try to write to FLASH the debugger goes to boot_cortex_m.c file and is stuck in this function

__attribute__((section(".text:_c_int00_noargs"), used, naked))
void _c_int00_noargs(void)
{
_c_int00_template(0, 1);
}

and when I try to reflash it then I receive this error

CORTEX_M4_0: Flash Programmer: Flash programming timed out.
CORTEX_M4_0: File Loader: Verification failed: Values at address 0x00000000 do not match Please verify target memory and memory map.
CORTEX_M4_0: GEL: File: C:\Users\drai\Documents\Repos\PoE_Digital\ats-poeclock\Debug\ats-poeclock.out: a data verification error occurred, file load failed.

And once I encounter this issue, I have to reflash it and it re-programs the board and again same cycle happens.

Regards,

Deepak

Can you check if you have correct TM4C1294NCPDT?

Charles,

I verified and all three things that you mentioned are same. 

regards,

Deepak

Deepak Rai said:

I am able to program but in my code I need to save some values in Flash memory and that's when I see these events.

Are you saving to flash or EEprom? At what address are you writing to the flash?

Can you show your code snippet?

HI Charles, I'm saving to Flash memory using function FlashPBSave.

// Write updated local structure to flash
TimerIntDisable (TIMER1_BASE, TIMER_TIMA_TIMEOUT); // Disable Timer1's Timer A timer
FlashPBSave ((unsigned char *) &Parms); // Save the Flash Parameters.
TimerIntEnable (TIMER1_BASE, TIMER_TIMA_TIMEOUT); // Enables Timer1's Timer A timeout interrupt

This is what I'm using.

I have used this to initialize it.

void Parms_init(PARAMETERS* parms) {

unsigned char *pucBuffer;

// Verify that the parameter block structure matches the FLASH parameter block size.
ASSERT(sizeof(PARAMETERS) == FLASH_PB_SIZE);

FlashPBInit(FLASH_PB_START, FLASH_PB_END, FLASH_PB_SIZE); // Initialize the Parameter block.

pucBuffer = FlashPBGet(); // Get a pointer to the latest parameter block in flash.

if (pucBuffer) { //Returns Null if no parameter block exists.
PRINT_CYAN("Parms using saved block\n");
memcpy(parms, pucBuffer, sizeof(PARAMETERS)); //Copy parameter block out of flash.
} else { //If no parameter block exists, active parameters are the factory defaults.
PRINT_CYAN("Parms using factory default\n");
memcpy(parms, &ParmsFactory, sizeof(PARAMETERS));
}

}

#define FLASH_PB_START 0xF0000

#define FLASH_PB_END 0xF4000

#define FLASH_PB_SIZE 512

I don't think the function is a issue because we have been using this for years and no change has been made apart from switching the MCUs.

Regards,

Deepak 

Do you have the space to allocate 32KB (two erase sectors) to the flash parameter blocks? For fault-tolerant operation a minimum of two erase blocks is required. Also, see this post: https://e2e.ti.com/support/microcontrollers/other/f/908/t/646502?TM4C129ENCPDT-FlashPBSave-fails-after-8-times

HI Bob,

I don't have extra 16KB memory but still for test purposes I tried what you suggested but this is also not working.

Even on the first save, my code goes to this function

__attribute__((section(".text:_c_int00_noargs"), used, naked))
void _c_int00_noargs(void)
{
_c_int00_template(0, 1);
}

and is stuck there. I want to know what is causing that. This is the main reason I'm getting data verification error after that.

Regards,

Deepak

Can you cut down your project such that you still have the error, but it can be run on an EK-TM4C1294XL LaunchPad and still reproduce the error? Then if you could send me the stripped down project, I might be able to do some debug on it.

Bob,

It's not easy for me to do that. It will take lot of time.

I don't know whats really going on. Yesterday FlashPBSave was working good and the today again the issue has started. And I haven't changed anything.

Is there any other way to check it?

Regards,

Deepak

I understand the difficulty, but it is much faster to isolate a problem by starting with a failing system and making changes to find what stops making it fail than trying to recreate the problem independently.  Let me suggest as a first step, disable the timer interrupt that you use as a timeout for the parameter block write and let's see if that has an impact.

Bob,

I did try that. It didn't make any difference. I also tried XDS 100 Debug Probe and still no change.

I was trying some changes when i saw one of my previous commits was working. And the change between the previous commit and new code has no relation to FlashPBSave function. But removing those changes got my code working after some time it started to go into this function again.

__attribute__((section(".text:_c_int00_noargs"), used, naked))
void _c_int00_noargs(void)
{
_c_int00_template(0, 1);
}

The previous statement being executed which leads to the previous function is

MAP_FlashProgram((uint32_t *)pui8Buffer, (uint32_t)pui8New, g_ui32FlashPBSize);  in FlashPBSave function.

As you said, I have 32KB flash available for parameter block. 

Right now I can break my code by just adding 2 lines of code which has no relation to anything. I want to know what is causing this because every time I add something new it stops working and after sometime it breaks and again starts working with addition of new line of code that i removed earlier.

I checked my memory allocation, currently I'm using 428KB(40%) of Flash and then last 90KB is being used for other settings to be saved in memory out of which 32KB is for Parameter Block. 

Is there anything that I need to take into account regarding the flash memory of NCPDT?

Regards,

Deepak

Put a breakpoint on the call to MAP_FlashProgram() and verify that all three parameters are 32-bit aligned (a number divisible by four without remainder).

Bob,

I verified that all three values are same in both case, when Its breaking and when its working.

I also noticed that in the code thats not working, if I put a breakpoint on MAP_FlashProgram(), my code keeps executing the same line of MAP_FlashProgram() over and over and if I remove the break point and run the same breaking code, it goes to this function

__attribute__((section(".text:_c_int00_noargs"), used, naked))
void _c_int00_noargs(void)
{
_c_int00_template(0, 1);
}

And the code that's working, even if put break point on MAP_FlashProgram(), the code resumes once I continue.

Regards,

Deepak

Are your running a real time operating system? If so, which one?

No. It's not a RTOS Project.

I'm still getting this issue and it's getting really difficult to track it down. There's no correlation with the changes that I'm making.

I still don't get why FlashPBSave will have issues as long as the values given to it are correct and there's memory available.

-Deepak

Bob,

I have noticed that when I'm debugging I get this 

_c_int00_noargs() which I don't think I used to get. Any Ideas why this is happening?

-Deepak

I don't recognize that, although it looks like the reset entry point. Which compiler are you using?

Its 18.12.2 

-Deepak

The _c_int00_noargs() is just the startup function that eventually calls main(). It looks like you hit a breakpoint on line 210 in the function main() in the file poeclock.c. Did you have a breakpoint set at that point?