• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 83 subscribers
  • Views 14825 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Load Program Error : .out : a data verification error occurred, file load failed.

Hailey Na
Prodigy 10 points
Other Parts Discussed in Thread: MSP430F417, MSP-TS430PM64, MSP430G2452, TMS320F28335

Hello.

During load a program, I met trouble.

I try to run example program on MSP430F417 socket board (MSP-TS430PM64).

Then, the error occured in debug and run session.

"Load Program Error: .out: a data verification error occurred, file load failed."

In order to resolve this problem, I checked project properties setting and general setup in .ccxml file.

However, I couldn't find any something strange.

If you had been this problem, please let me know.

Thank you.

 

  • 0
    Genius 4090 points

    You can search the forum if such questions are already asked,

    one similar discussion here: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/231145.aspx?pi70789=1

  • 0
    Prodigy 50 points

    hi, 

    I am working on the msp430g2452 (with the msp-exp430g2) on the ccsv5.3.0 and even when i try to flash a simple code example i'm getting the following error:

    "MSP430: Trouble Writing Memory Block at 0xfffe on Page 0 of Length 0x2: Could not write device memory
    MSP430: GEL: File: D:\svecg\ccs\wksp1\test_2452\Debug\test_2452.out: Load failed. "

     I was able to flash the same program successfully last week. I have read the verified answers on other posts but there is nothing substantial there - they have all based it on some layout issue etc , which i dont think is the case on my side. I am not able to figure out why this occurs and how to resolve it.

    Any help would be appreciated. thanks

  • 0 in reply to rishap_77
    Guru 227245 points

    The two main reasons for failed programming are corroded contats on the JTAG connection or a power supply that drops voltage beyond a certain maximum change when the flash writing causes the supply current to suddenly go up (causing the flash controller to flag a write failure)

  • 0 in reply to Jens-Michael Gross
    Prodigy 70 points

    Hi Jens-Michael,

    thanks to your simple answer I've solved my strange problem... I've changed 2 x 10uF filter capacitors by 2 x 27uF and all is working.

    Always is interesting to check if power supply is switched on before test a circuit!


    Thanks

  • 0 in reply to FERMIN ALARCON
    Prodigy 10 points
    im getting this error,

    can anyone tell me why this happened?

    MSP430: File Loader: Data verification failed at address 0x0000C000 Please verify target memory and memory map.
    MSP430: GEL: File: C:\Users\ANILKUMAR\workspace_v6_0\asd\Debug\asd.out: a data verification error occurred, file load failed.
  • 0 in reply to SREENATH VIJAYAKUMAR
    Prodigy 70 points
    Hi, Sreenath,

    your are using your own hardware? If it is, then ensure that your supply voltage don't drop at the moment of starting debugging using one oscilloscope.

    In my case this was the problem, voltage drops a little sometimes and TMS320F28335 returns error to the debugger.

    I was using one example and sometimes work and sometimes don't work.

    At first moment "the simple way" to bypass the problem was to restart computer. Now, it works every time I compile and debug!

    Regards.
  • 0
    Intellectual 820 points
    HI all,

    I want to contribute my solution to the same error in hopes it's someone else's solution as well. I've used this discussion as a stepping stone to help solve my same problem.

    My project had no errors in it and a few warnings but I thought it should load in without any issue. My warnings were mentioning something about undefined SECTIONS for .int16, .int17, etc. But it wouldn't load in because of this same data verification error. I eventually realized I was working on an older project and found that the way we defined ISR's back then were different than the way we do now. I solved my issue by changing the folowing lines:

    #pragma vector=ADC12_VECTOR
    __interrupt void ADC12ISR(void)

    to

    #pragma CODE_SECTION(ADC12ISR, ".text:_isr")
    __interrupt void ADC12ISR(void)

    The warnings for the ISR's went away and the project loaded in just fine. Note that the underscore in ".text:_isr" is absolutely needed as you can get thrown under the bus with a nasty Linker issue like I did once. Without it, the Linker can put functions in memory sections they should not be in and cause sanity-grinding processor resets. We do also have a Proxy Vector table that simply redirects interrupts generated to go to a specific "__interrupt " defined function, but it was taken straight from TI example code and isn't anything unique to us.

    Hope this helps anyone,
  • 0 in reply to Lunatic911
    Guru 227245 points
    This is a strange thing. The vector-pragma should tell compiler and linker implicitly that the code needs to be placed in the lower text, as
    there cannot be any 20 bit vector.
    Teh CODE_SECTIONS pragma tells the linker that the code has to be placed in the _isr part of t .text (which is always in lower 64k).
    But without the vector pragma, nobody knows that an interrupt vcector should point to it.

    The warnings for undefined sections are strange. It seems that the code (or rather, the linker script) in your project doesn't really match the way interrupt vectors are handle dby your current IDE. This may happen when you have old projects and update the IDE.
    If it were for the wrong placement of code, th elinker would complain for overfull section (trying to put a 20 bit address into a 16 bit verctor section.

    Now you say you use a proxy vector table. If you do, then the 16 bit vectors point into the table, and the table contains the real ISR address - which can very well be 20 bit. In this case, the real ISR can be located anywher ein memory, only the proxy table (or the jumptable) needs to contain (jump instructions with) 20/32 bit address of the ISR.

    In any case, the compiler needs to know that the function is an ISR. Else the compiler doesn't know that it has to end with an RTI instruction and that R12-R15 need to be preserved. The __interrupt keyword does this.

**Attention** This is a public forum