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.

HELP!!! MSP430: File Loader: Data verification failed...

Other Parts Discussed in Thread: MSP430F1232, MSP430F2274

Hi!

Having a strange problem. When using port2 ISR I get the following error:

MSP430: File Loader: Data verification failed at address 0x0000FFEA Please verify target memory and memory map.
MSP430: GEL: File: C:\Users\a0797143\workspace_v5_4\BlinkLED\Debug\BlinkLED.out: a data verification error occurred, file load failed.

MSP430F1232

For illustration I stripped down all the code to the essentials below. If I remove the port2 ISR everything works just fine. What am I missing here?

I am using CCS V5.4, freshly installed today.

#include <msp430x12x2.h>

void main(void)
{
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
P1DIR |= 0x40; // P1.0 output
CCTL0 = CCIE; // CCR0 interrupt enabled
CCR0 = 20000;
TACTL = TASSEL_2 + MC_1; // SMCLK, upmode

_BIS_SR(LPM0_bits + GIE); // Enter LPM0 w/ interrupt
}


#pragma vector=PORT1_VECTOR
__interrupt void PORT1 (void)
{
P1OUT ^= 0x40; // Toggle P1.0
}


#pragma vector=PORT2_VECTOR
__interrupt void PORT2 (void)
{
P1OUT ^= 0x40; // Toggle P1.0
}


#pragma vector=ADC10_VECTOR
__interrupt void ADC10_ISR (void)
{
P1OUT ^= 0x40; // Toggle P1.0
}

// Timer A0 interrupt service routine
#pragma vector=TIMERA0_VECTOR
__interrupt void Timer_A (void)
{
P1OUT ^= 0x40; // Toggle P1.0
}

  • Klaus Seiberts said:
    MSP430: File Loader: Data verification failed at address 0x0000FFEA Please verify target memory and memory map.

    That is the ADC10 interrupt vector, which is a valid address in flash to be written for your program.

    I don't have a MSP430F1232 to attempt to invesitgate, so suggest you try and determine if the error is in CCS or not by:

    1) Set the CCS project to also generate a TI-TXT format flash image. From the CCS project properties Build -> Steps -> Post Build Steps apply a predefined stop of "Create flash image: TI-TXT"

    2) Attempt to download the program in CCS. After CCS has reported the verification failure, use the Elprotonic FET-Pro430 (the free version is sufficient) to open the TI-TXT flash image and verify flash. This will show if the flash as written by CCS is correct or not.

    3) If the verification in the previous step fails, then attempt to program and verify the flash using FET-Pro430.

  • Klaus Seiberts said:
    ...  failed at address 0x0000FFEA ... If I remove the port2 ISR everything works just fine. ...

    Are you sure the failed location is 0x0000FFEA and not 0x0000FFE6?

    What happens if you remove the ADC10 ISR instead of the port2 ISR?

  • Thanks for looking into this.

    Yes, I am sure as I just copied the failure message.

    I tried many combinations and as long as the port2 ISR is in the code, it will fail. Removing the ADC10 ISR instead of the port2 ISR is not making the failure go away.

  • Hi, I hit the wrong button. The question is unfortunately not answered.

    I did all the stepts you proposed: The VERIFY FLASH returned with an error (JTAG and SECURITY fuse tests passed). Flashing the SW with the flash tool was successful.

    I guess we are looking at a CCS problem, right?

  • Klaus Seiberts said:
    Hi, I hit the wrong button. The question is unfortunately not answered.

    You should be able to unverify the answer by clicking the "No" button on "Did this answer your question?"
    Klaus Seiberts said:
    I guess we are looking at a CCS problem, right?
    It does look like a CCS problem. Before starting the failed download attempt in CCS can you go to CCS Support -> Debug Server Log and enable debug server logging. If you attach the debug server log that might give a clue about the cause of the failure.

  • Klaus Seiberts said:
    I tried many combinations and as long as the port2 ISR is in the code, it will fail. Removing the ADC10 ISR instead of the port2 ISR is not making the failure go away

    This Again: data verification error occurred thread contains an example which causes a data verification failure when only the PORT2_VECTOR is defined, so does appear to a problem with PORT2_VECTOR.

  • 2287.BT.txt

    Hi Chester,

    here the log file. I hope it can give you a clue...

    Thanks,

    Klaus

  • Yes, this seems to be exactly the same problem. Unfortunately, no solution yet.

  • Klaus Seiberts said:

    here the log file. I hope it can give you a clue...

    Loking at the sequence of the memory options in the log file shows:

    1) All the main flash memory being erased:

    0x00001654 649529 3 MSP430 MSP C: MSP430_Erase( 1, 0xE000, 0x2 )
    0x00001654 650060 3 MSP430 MSP R: MSP430_Erase( 1, 0xE000, 0x2 ) = 0

    2) The code being written to flash:

    0x00001654 650060 3 MSP430 MSP C: MSP430_Memory( 0xE000, 5B925F48, 0x9C4, 0 )
    0x00001654 650606 3 MSP430 MSP R: MSP430_Memory( 0xE000, 5B925F48, 0x9C4, 0 ) = 0

    3) The code being read from flash for verification:

    0x00001654 650653 3 MSP430 MSP C: MSP430_Memory( 0xE000, 31AC0208, 0x9C4, 1 )
    0x00001654 650793 3 MSP430 MSP R: MSP430_Memory( 0xE000, 31AC0208, 0x9C4, 1 ) = 0

    4) The interrupt vectors for PORT1 and PORT2 being written to flash:

    0x00001654 650793 3 MSP430 MSP C: MSP430_Memory( 0xFFE4, 5B925F48, 0x4, 0 )
    0x00001654 650918 3 MSP430 MSP R: MSP430_Memory( 0xFFE4, 5B925F48, 0x4, 0 ) = 0

    5) The interrupt vectors for PORT1 and PORT2 being read from flash for verification:

    0x00001654 650918 3 MSP430 MSP C: MSP430_Memory( 0xFFE4, 31AC0208, 0x4, 1 )
    0x00001654 650933 3 MSP430 MSP R: MSP430_Memory( 0xFFE4, 31AC0208, 0x4, 1 ) = 0

    6) The interrupt vector for ADC10 being written to flash:

    0x00001654 650933 3 MSP430 MSP C: MSP430_Memory( 0xFFEA, 5B925F48, 0x2, 0 )
    0x00001654 655723 3 MSP430 MSP R: MSP430_Memory( 0xFFEA, 5B925F48, 0x2, 0 ) = 0

    7) The interrupt vector for ADC10 being read from flash for verification:

    0x00001654 655723 3 MSP430 MSP C: MSP430_Memory( 0xFFEA, 31AC0208, 0x2, 1 )
    0x00001654 655723 3 MSP430 MSP R: MSP430_Memory( 0xFFEA, 31AC0208, 0x2, 1 ) = 0

    8) A verification error being reported for the ADC10 interrupt vector at flash address 0xFFEA which matches you error reported on the CCS GUI:

    0x00001654 655723 3  COM_DBG_IF C: class dsDebugger::OnError()
    0x00001654 655723 3  XPCOM C: ( (dsIStringEventCallback*)3396EFF0 )->onEvent( MSP430: File Loader: Data verification failed at address 0x0000FFEA Please verify target memory and memory map. )

    9) No more flash memory accesses are attempted following the verification failure.

    Based upon the information in the log file I can't see anything which CCS is obviously doing wrong, and since the logging doesn't record the actual data written to or read from flash can't be sure if the problem is in CCS or the MSP430 dll.

    Since I can't repeat the failure with the devices I have, and don't currently have a MSP430F1232 suggest you report the problem on the Code Composer Studio forum, with a link to this thread.

  • OK, have finallly managed the repeat the failure with a MSP430F2274. Using CCS 5.4.0.00091, MSP-FET430UIF v1.4a, MSP430.dll v3.3.0.6 and the example program posted above. The TI-TXT format flash image had the following to be programmed into the interrupt vectors:

    @ffe4
    B4 80 BC 80
    @ffea
    AC 80
    @fff2
    C4 80
    @fffe
    82 80

    On the first download attempt CCS reported a verification failure at address 0xFFEA. Reading the flash using FET-Pro430 showed the following in the interrupt vectors:

    0xFFE0: FF FF FF FF B4 80 BC 80 FF FF FF FF FF FF FF FF | ................
    0xFFF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 FF | ................

    On the second and third download attempts CCS reported a verification failure at address 0xFFF2. Reading the flash using FET-Pro430 showed the following in the interrupt vectors:

    0xFFE0: FF FF FF FF B4 80 BC 80 FF FF AC 80 FF FF FF FF | ................
    0xFFF0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 FF | ................

    As well as the words at address 0xFFEA and 0xFFF2 being erased, rather than programmed, there is also the byte at address 0xFFFE which reads incorrectly back as zero.

  • Wow and thanks a lot for working on this.

    I am surprised to learn that the on of the F2xxx series is having the same problem as I somehow thought it had to do with the old F1xxx devices.

    What should I do from here?

    Klaus

  • Klaus Seiberts said:
    What should I do from here?

    As you are a TI Employee could you get the CCS developers to take a look at this problem?

    Out of curriosity I was going to try and log the actual data being passed into the MSP430_Memory API calls by CSS in an attempt conclusively prove if the error is in CCS or not.

    (TI have made the MSP430.dll open-source so I can debug that, but CCS itself is still closed-source so I can't debug CCS)

  • I used API monitor to trace the calls made by CCS to MSP430_Memory in MSP430.dll, when CCS reported the error:

    MSP430: File Loader: Data verification failed at address 0x0000FFEA Please verify target memory and memory map.

    MSP430: GEL: File: C:\Documents and Settings\Mr_Halfword\workspace_v5_4\ISR_causes_download_error\Debug\ISR_causes_download_error.out: a data verification error occurred, file load failed.

    The TI-TXT flash image file says the byte values AC 80 should be programmed at the ADC10 interrupt vector address of 0xFFEA. The following shows CCS correctly calling MSP430_Memory to write 2 bytes with values AC 80 (initial 2 bytes shown in the Hex buffer pre-call) to address 0xFFEA (65514):

    The following shows CCS calling MSP430_Memory to verify the previous flash write to the 2 bytes at address 0xFFEA, but getting the readback of the bytes values FF FF (initial 2 bytes shown in the Hex buffer post-call):

    Reading the interrupt vectors from the flash using FET-Pro430 after the CCS verification failure confirms that the flash word at address 0xFFEA has the erased value of FF FF, as well as the byte value of 00 at address 0xFFFE which CCS didn't attempt to program:

    0xFFE0: FF FF FF FF B4 80 BC 80   FF FF FF FF FF FF FF FF | ................
    0xFFF0: FF FF FF FF FF FF FF FF   FF FF FF FF FF FF 00 FF | ................
    The conclusion is that CCS is attempting to program the correct interrupt vectors into flash via the MSP430.dll, but for some reason the MSP430.dll and/or MSP-FET430UIF firmware fails to program the flash correctly.

    Therefore, the problem looks to be in the MSP430.dll software and/or FET firmware.

    Given that the FET-Pro430 is able to correctly program interrupt vectors using the same MSP430.dll software and FET firmware which fails when CCS attempts the download, comparing the difference in how CCS and FET-Pro430 call the MSP430.dll API may provide a clue.

  • Chester, great work, thanks a lot.

    I will get TI folks involved.

    Will let you know the outcome.

    Thanks again and best regards,

    Klaus

  • Chester Gillon said:
    OK, have finallly managed the repeat the failure with a MSP430F2274. Using CCS 5.4.0.00091, MSP-FET430UIF v1.4a, MSP430.dll v3.3.0.6 and the example program posted above.

    MSP430.dll v3.3.0.6 is the latest binary version which is installed with CCS 5.4. I have rebuilt the MSP430.dll from source for v3.2.5.4 which is the latest source available in SLAC460e, and the v3.2.5.4 showed the same failure.

    Looking at USB communication logging, enabled when the MSP430.dll is compiled for debugging, I can see the correct flash address and data being sent but the flash gets programmed incorrectly. This suggests a problem in the firmware which runs in the MSP-FET430UIF and/or the flash write "funclet" which gets downloaded into the RAM of the target MSP430 to program the flash (where the MSP-FER430UIF firmware and funclets are stored in tables inside the MSP430.dll).

    In the initial tests the MSP430F2274 target board jumpers were set for SBW, and changing the jumpers to JTAG didn't stop the failure.

  • Using the same setup (CCS5.4.0.00091, UIF 1.4a, DLL v3.3.0.6) with the above program, I can't reproduce the error on either a 1232 or two different 2274. I also tried manually executing all steps according to the CCS log.

    I'm using a TS430DA38 socket board rev. 1.3. Even deliberate misconfiguration of the jumpers (including removing all of them) didn't result in any errors during flashing. Given that it consistently fails at the same address, I could use any information I can get (project settings, hardware revisions, etc.)

  • Alexander Festini said:
    Using the same setup (CCS5.4.0.00091, UIF 1.4a, DLL v3.3.0.6) with the above program, I can't reproduce the error on either a 1232 or two different 2274

    My failure occured with CCS running under Windows XP SP3. Are you using Windows or Linux?

    Alexander Festini said:
    I also tried manually executing all steps according to the CCS log.

    I could also trying enabling the logging in the DLL which records the USB communication with the MSP-430FETUIF in case this gives a clue.

    [I did try and use a LSA to capture the communication between the MSP-430FETUIF and the MSP430 target, but the amount of data exceeded the storage of my LSA]

  • I'm on a 64bit Win7, so that might be something to try. Though it does seem like the problem is beyond the PC side. A communication log might actually help, even if it's just to see if the data is correctly aligned and padded.

  • Alexander Festini said:
    I'm on a 64bit Win7, so that might be something to try. Though it does seem like the problem is beyond the PC side. A communication log might actually help, even if it's just to see if the data is correctly aligned and padded.

    I have attached 4263.ISR_causes_download_error.zip which is my example project plus diagnostic logs. This was a verification failure at address 0xFFEA using:
    - CCS 5.4.0.00091 running on Windows XP SP3
    - Target MSP430F2274
    - MSP-FET430UIF v1.4a
    - MSP430.dll v3.3.1.3 compiled for debug from the latest source code in SLAC430f

    The files of interest are:
    - ISR_causes_download_error\Debug\ISR_causes_download_error.txt - The TI format text file of the executable
    - ISR_causes_download_error\CCS_debug_server.log - The CCS debug server log file
    - ISR_causes_download_error\comm.log - The communication log from MSP430.dll
    - ISR_causes_download_error\FET-Pro430_read_after_failure.txt - The flash contents read using FET-Pro430 after CCS reported the verification failure

  • Alexander Festini said:
    A communication log might actually help, even if it's just to see if the data is correctly aligned and padded.

    I have had a look at the communication logs attached in my previous post. The byte sequence B4 80 BC 80 gets sucessfully programmed at adress ffe4, and the following in the communication log showing the address (little endian) and data sent to the MSP-FET430UIF highlighted in green:

    2013-Jul-20 17:19:57.968750 send: d1c
    [1f][81][26][00][1f][00][00][02][80][00][00][02][e4][ff][00][00][02][00][00][00][00][00][08][a5][80][00][88][00][b4][80][bc][80][b7][24]

    The next part of the image to be programmed is the bytes AC 80 at address ffea. The protocol for sending data aligns to a 4 byte address and pads the data with FFs. The communication log shows the expected data being sent to the MSP-FET430UIF, with the address aligned at ffe8 and the data padded FF FF AC 80:

    2013-Jul-20 17:19:58.187500 send: d1c
    [1f][81][07][00][1f][00][00][02][80][00][00][02][e8][ff][00][00][02][00][00][00][00][00][08][a5][80][00][88][00][ff][ff][ac][80][c1][5b]

    Therefore, as far as I can tell in the failure case the data sent to the MSP-430FETUIF is correctly aligned and padded.

    The other thing I have noticed is that when flash is succesfully programmed the write operation takes a few hundred milliseconds, whereas the failure case takes 5 seconds. Where the delay is shown in both:
    - The CCS debug server log, between the call to MSP430_Memory and the call returning.
    - The communication log, between the command being sent to the MSP-FET430UIF and the response being received.

  • Alexander Festini said:
    Given that it consistently fails at the same address, I could use any information I can get (project settings, hardware revisions, etc.)

    I wasn't clear, but with CCS I found the failure is sometimes at a different address (but I have never seen CCS succesfully program the example program into my MSP430F2274). My target board is a Texas Instruments MSP-CB430DA38 Rev 1.0 fitted with a device marked "58DRF7T X430F2274A". I.e. experimental silicon.

    To try and elliminate CCS from being the cause of the programming failure, a VS2010 program was created which makes a minimum set of calls to the MSP430.dll to program the same main program and interrupt vectors as done by CCS. The attached 4382.ISR_causes_download_error.zip contains the test program, as a VS2010 solution.

    With the test program, a MSP-FET430UIF v1.4a and the TI MSP430.dll v3.3.1.3 compiled for debug get a verification failure at address 0xFFEA in the same way as when programmed under CCS:

    USB I/F 0 COM13 enabled status = 0
    FET FW version = 3.3.1.3
    VCC  in[mV]: 3000
    VCC out[mV]: 2992
    VCC out[mV]: 3047
    num of devices 1
    JtagID: 89
    Found device MSP430F2274
    92 30 00 ff ff
    Error: HAL macro returned error
    Erase device main memory
    Programming 212 bytes at address 32768
    Programming 4 bytes at address 65508
    Programming 2 bytes at address 65514
    Verification failure at address 65514

    The above output from the program is a mixture of standard out from the test program, and from the MSP430.dll (enabled when compiled for debug). The attached file also contains:
    - ISR_causes_download_error\Debug\comm.log - The MSP430.dll communication log from the above failure
    - ISR_causes_download_error\Debug\FET-Pro430_read_after_failure.txt - The contents of the MSP430F2274 flash as read by FET-Pro430 after the above failure

    Using the same test program and target board, but an Olimex MSP430-JTAG-TINY-V2 with Olimex MSP430.dll v2.0.0.7 are able to succesfully program the MSP430F2274:

    USB I/F 0 TNV2 00000000 enabled status = 0
    FET FW version = 2.0.0.7
    Found device MSP430F2274
    Erase device main memory
    Programming 212 bytes at address 32768
    Programming 4 bytes at address 65508
    Programming 2 bytes at address 65514
    Programming 2 bytes at address 65522
    Programming 2 bytes at address 65534
    Using an Olimex MSP430-JTAG-ISO-MK2 was also able to sucesfully program the MSP430F2274
    USB I/F 0 ISOV2 00000000 enabled status = 0
    FET FW version = 2.0.0.7
    Found device MSP430F2274
    Erase device main memory
    Programming 212 bytes at address 32768
    Programming 4 bytes at address 65508
    Programming 2 bytes at address 65514
    Programming 2 bytes at address 65522
    Programming 2 bytes at address 65534
    Wwhile my target device has experimental silicon, the fact that two different Olimex programmers can flash the example program, which fails with the TI MSP-FET430UIF makes me still think that there is a problem with the MSP-FET430UIF hardware / firmware / software.

  • Chester Gillon said:
    Reading the interrupt vectors from the flash using FET-Pro430 after the CCS verification failure confirms that the flash word at address 0xFFEA has the erased value of FF FF, as well as the byte value of 00 at address 0xFFFE which CCS didn't attempt to program:

    0xFFE0: FF FF FF FF B4 80 BC 80   FF FF FF FF FF FF FF FF | ................
    0xFFF0: FF FF FF FF FF FF FF FF   FF FF FF FF FF FF 00 FF | ................

    [/quote]On further investigation I don't think the byte value of 00 at address 0xFFFE is actually programmed into flash, but is a sign the MSP-FET430UIF isn't reading the byte at address 0xFFFE correctly. E.g. the following sequence is repeatable:

    1) Use the PC ISR_causes_download_error test program with MSP-FET430UIF v1.4a and MSP430.dll v.3.3.1.3 to attempt to program the MSP430F2274, which fails with a data verification error at address 0xFFEA. This means the test program hasn't attempted to program the interrupt vectors at address 0xFFF2 and 0xFFFE:

    USB I/F 0 COM13 enabled status = 0
    FET FW version = 3.3.1.3
    VCC  in[mV]: 3000
    VCC out[mV]: 3048
    VCC out[mV]: 3049
    num of devices 1
    JtagID: 89
    Found device MSP430F2274
    Erase device main memory
    Programming 212 bytes at address 32768
    Programming 4 bytes at address 65508
    Programming 2 bytes at address 65514
    Verification failure at address 65514

    2) After the verification failure, read the flash with MSP-FET430UIF v1.4a and MSP430.dll v.3.3.1.3 using FET-Pro430, which showed the byte at address 0xFFFE was 0x00: 

    === Information Memory Segments  0x1000 - 0x10FF ======

    0x1000:       ------- b l a n k ----(all 0xFF)-------


    0x10F0: FF FF FF FF FF FF FF FF   D8 0E 6F 0E D7 0C 91 06 | ..........o.....

    ========== Main Memory Segments  0x8000 - 0xFFFF ======


    0x8000: 0A 12 09 12 3F 40 00 00   3F 90 01 00 19 28 3F 40 | ....?@..?....(?@
    0x8010: 00 00 3F 90 01 00 14 28   3A 40 00 00 3A 80 00 00 | ..?....(:@..:...
    0x8020: 3A 50 03 00 0A 11 0A 11   39 40 00 00 3C 49 7F 4C | :P......9@..<IL
    0x8030: 4F 4F 0F 5F 1F 4F 00 00   3D 49 8F 12 1A 83 F6 23 | OO._.O..=I.....#
    0x8040: 3F 40 00 00 3F 90 00 00   08 24 3A 40 00 00 02 3C | ?@..?....$:@...<
    0x8050: 3F 4A 8F 12 3A 90 00 00   FB 23 30 40 A6 80 B2 40 | ?J..:....#0@...@
    0x8060: 80 5A 20 01 F2 D0 40 00   22 00 B2 40 10 00 62 01 | .Z ...@."..@..b.
    0x8070: B2 40 20 4E 72 01 B2 40   10 02 60 01 32 D0 18 00 | .@ Nr..@..`.2...
    0x8080: 30 41 31 40 00 06 B0 12   CC 80 0C 93 02 24 B0 12 | 0A1@.........$..
    0x8090: 00 80 0C 43 B0 12 5E 80   B0 12 D0 80 34 41 35 41 | ...C..^.....4A5A
    0x80A0: 36 41 37 41 38 41 39 41   3A 41 30 41 F2 E0 40 00 | 6A7A8A9A:A0A..@.
    0x80B0: 21 00 00 13 F2 E0 40 00   21 00 00 13 F2 E0 40 00 | !.....@.!.....@.
    0x80C0: 21 00 00 13 F2 E0 40 00   21 00 00 13 1C 43 30 41 | !.....@.!....C0A
    0x80D0: 03 43 FF 3F FF FF FF FF   FF FF FF FF FF FF FF FF | .C.?............
    0x80E0:       ------- b l a n k ----(all 0xFF)-------


    0xFFE0: FF FF FF FF B4 80 BC 80   FF FF FF FF FF FF FF FF | ................
    0xFFF0: FF FF FF FF FF FF FF FF   FF FF FF FF FF FF 00 FF | ................

    3) Change the MSP-430FETUIF to an Olimex MSP430-JTAG-ISO-MK2 and re-read the flash with FET-Pro430. This reports that the byte at address 0xFFFE is 0xFF (which is expected as that address wasn't programmed):

    === Information Memory Segments  0x1000 - 0x10FF ======

    0x1000:       ------- b l a n k ----(all 0xFF)-------


    0x10F0: FF FF FF FF FF FF FF FF   D8 0E 6F 0E D7 0C 91 06 | ..........o.....

    ========== Main Memory Segments  0x8000 - 0xFFFF ======


    0x8000: 0A 12 09 12 3F 40 00 00   3F 90 01 00 19 28 3F 40 | ....?@..?....(?@
    0x8010: 00 00 3F 90 01 00 14 28   3A 40 00 00 3A 80 00 00 | ..?....(:@..:...
    0x8020: 3A 50 03 00 0A 11 0A 11   39 40 00 00 3C 49 7F 4C | :P......9@..<IL
    0x8030: 4F 4F 0F 5F 1F 4F 00 00   3D 49 8F 12 1A 83 F6 23 | OO._.O..=I.....#
    0x8040: 3F 40 00 00 3F 90 00 00   08 24 3A 40 00 00 02 3C | ?@..?....$:@...<
    0x8050: 3F 4A 8F 12 3A 90 00 00   FB 23 30 40 A6 80 B2 40 | ?J..:....#0@...@
    0x8060: 80 5A 20 01 F2 D0 40 00   22 00 B2 40 10 00 62 01 | .Z ...@."..@..b.
    0x8070: B2 40 20 4E 72 01 B2 40   10 02 60 01 32 D0 18 00 | .@ Nr..@..`.2...
    0x8080: 30 41 31 40 00 06 B0 12   CC 80 0C 93 02 24 B0 12 | 0A1@.........$..
    0x8090: 00 80 0C 43 B0 12 5E 80   B0 12 D0 80 34 41 35 41 | ...C..^.....4A5A
    0x80A0: 36 41 37 41 38 41 39 41   3A 41 30 41 F2 E0 40 00 | 6A7A8A9A:A0A..@.
    0x80B0: 21 00 00 13 F2 E0 40 00   21 00 00 13 F2 E0 40 00 | !.....@.!.....@.
    0x80C0: 21 00 00 13 F2 E0 40 00   21 00 00 13 1C 43 30 41 | !.....@.!....C0A
    0x80D0: 03 43 FF 3F FF FF FF FF   FF FF FF FF FF FF FF FF | .C.?............
    0x80E0:       ------- b l a n k ----(all 0xFF)-------


    0xFFE0: FF FF FF FF B4 80 BC 80   FF FF FF FF FF FF FF FF | ................
    0xFFF0:       ------- b l a n k ----(all 0xFF)-------

    4) Change back to the MSP-430FETUIF. Use FET-Pro430 to erase main memory only. Read flash in FET-Pro430, which reports byte at 0xFFFE with the value 0x00:

    == Information Memory Segments  0x1000 - 0x10FF ======

    0x1000:       ------- b l a n k ----(all 0xFF)-------


    0x10F0: FF FF FF FF FF FF FF FF   D8 0E 6F 0E D7 0C 91 06 | ..........o.....

    ========== Main Memory Segments  0x8000 - 0xFFFF ======

    0x8000:       ------- b l a n k ----(all 0xFF)-------


    0xFFF0: FF FF FF FF FF FF FF FF   FF FF FF FF FF FF 00 FF | ................

    5) Change back to the Olimex MSP430-JTAG-ISO-MK2. Read flash in FET-Pro430, which reports all of the main memory is erased, as expected:

    === Information Memory Segments  0x1000 - 0x10FF ======

    0x1000:       ------- b l a n k ----(all 0xFF)-------


    0x10F0: FF FF FF FF FF FF FF FF   D8 0E 6F 0E D7 0C 91 06 | ..........o.....

    ========== Main Memory Segments  0x8000 - 0xFFFF ======

    0x8000:       ------- b l a n k ----(all 0xFF)-------

    6) Change back to the MSP-FET430UIF. Read flash using FET-Pro430 which reports address 0xFFFE as the value 0x00 again:

    === Information Memory Segments  0x1000 - 0x10FF ======

    0x1000:       ------- b l a n k ----(all 0xFF)-------


    0x10F0: FF FF FF FF FF FF FF FF   D8 0E 6F 0E D7 0C 91 06 | ..........o.....

    ========== Main Memory Segments  0x8000 - 0xFFFF ======

    0x8000:       ------- b l a n k ----(all 0xFF)-------


    0xFFF0: FF FF FF FF FF FF FF FF   FF FF FF FF FF FF 00 FF | ................

    The conclusion is that as well as the failure of the MSP-FET430UIF to program the flash correctly, the MSP-FET430UIF can also fail to report the correct contents of the byte at address 0xFFFE. Not sure if the two problems are related.

  • I tried to reproduce it again on XP and using your test program on different machines, but without success. However, we only have Rev E of the 2774 and 1.3 of the socket board. The errata for the 2774 also mention some issues on old revisions that might explain some or all of the observed issues.

    To make things more complicated, the other debuggers won't actually use the v3 of the DLL, but the embedded v2 (which isn't open source and only comes with the released DLL binaries). There have been some major changes in how devices are erased and programmed (using funclets rather than manually clocking the device). It might be possible that by basically having the device flash itself, the process is now also subject to some old errata.

    It might be worth getting a sample of a new revision and see if the problem still occurs on that.

    To rule out issues with the clock calibration process, you can either modify the open source version and have the ConfigManager always set freqCalibration to false, or place a file "MSP430DLL.INI" in the working directory containing the line "DCO_CALIBRATION OFF". This should only be used for testing, as otherwise programming might happen with a clock speed that is outside the allowed range for flashing.

  • Alexander Festini said:
    or place a file "MSP430DLL.INI" in the working directory containing the line "DCO_CALIBRATION OFF".

    I tried that, and the ISR_causes_download_error test program still failed. I set a breakpoint in the ConfigManagerV3::init function to confirm that the .ini file was being read and the freqCalibration member was set false.

    I also tried setting the SBW_SPEED and SBW_SPEED in the .ini file to the lowest values and that also didn't change the behavior.

    Alexander Festini said:
    It might be worth getting a sample of a new revision and see if the problem still occurs on that.
    I will try and get a newer revision.

     The original poster on this thread, and on another linked thread also had a Data Verification failure, but I can't see a note of what their silicon revisions were.

    Alexander Festini said:
    I tried to reproduce it again on XP and using your test program on different machines, but without success.

    maybe it wasn't clear, but after I posted that test program found that when used FET-Pro430 with the MSP-FET430UIF to erase the main program flash, and then read the flash their was one byte at address 0xFFFE which apparently read back as 0x00 rather 0xFF. I believe this is a problem with reading the flash with the MSP-FET430UIF as reading the flash of the same device in two Olimex FETs then showed all the main memory as 0xFF. If you haven't already done so, could you try and repeat that part of the test?

  • Also nothing I can reproduce, however, the errata have this for all 2274 up to rev D: "Flash addresses between 0xC000 and 0xffff might not be read correctly. Supply voltages and addressing mode affect the read value."

  • Alexander Festini said:
    Also nothing I can reproduce, however, the errata have this for all 2274 up to rev D: "Flash addresses between 0xC000 and 0xffff might not be read correctly. Supply voltages and addressing mode affect the read value."

    Thanks for the information. With my MSP430F2274 experimental silicon and MSP-FET430UIF also tried:
     - Setting the voltage to the minimum (2.2V) and maximum (3.6V) for flash programming, which didn't change the failure
    - Forcing the MSP430.dll interface mode to SPYBIWIRE_IF and SPYBIWIREJTAG_IF, which didn't change the failure

    Found two different boards with MSP430F2274 silicon revision E, but the MSP-FET430UIF MSP430_OpenDevice fails with "Unknown device" when tried to program them.

    Have ordered new MSP430F1232 and MSP430F2274 boards to try and get some more recent silicon revisions to try...

  • Chester Gillon said:
    Have ordered new MSP430F1232 and MSP430F2274 boards to try and get some more recent silicon revisions to try...

    Initial tests on the new devices:

    1) Using the same program, MSP430.dll v3.3.1.3 and MSP-FET430UIF v1.4a which got verification failures with a MSP430F2274 prototype silicon, now successfully programs a MSP430F2274 revision F device.

    2) With a MSP430F1232 revision D am getting verification failures at address 0xFFEA using the MSP-FET430UIF. Can successfully program the MSP430F1232 using an Olimex MSP430-JTAG-ISO-MK2. In MSP430F1232 Device Erratasheet SLAZ133C I can't see any flash errata listed.

    Given 2 there still might be a bug / timing problem in the MSP430.dll / firmware for the MSP-FET430UIF.

  • It seems others have been able to reproduce the problem with a F1232 rev D, though apparently only on a TS430DW28. Other packages have been reported as working. What is the revision of your socket board? I'm using rev 2.0 and even tried forcing errors with nonsensical jumper configurations without any success. Maybe just in case, the jumper settings might also be of interest.

  • I am using our own board. The device is soldered onto it.

  • I have been seing the problem with an Olimex MSP430-H1232 target board, which contains a soldered MSP430F1232 rev D part.

    The attached 4540.ISR_causes_download_error.zip is a Visual Studio 2010 project which shows the problem, by calling the MSP430.dll with the minimum set of flash programming to show the problem. It only attempts to program:

    a) Bytes 0xB4, 0x80, 0xBC, 0x80 at address 0xffe4

    b) Bytes 0xAC, 0x80 at address 0xffea

    The verification fails at the programming of address 0xffea (65514):

    ISR_causes_download_error.exe
    USB I/F 0 COM11 enabled status = 0
    FET FW version = 3.3.1.3
    Found device MSP430F12x2/F11x2
    Erase device main memory
    Programming 4 bytes at address 65508
    Programming 2 bytes at address 65514
    Verification failure at address 65514

    After the verification failure reading the flash with FET-Pro430 shows the data at arress 0xFFEA wasn't programmed:

    ========== Main Memory Segments  0xE000 - 0xFFFF ======

    0xE000:       ------- b l a n k ----(all 0xFF)-------


    0xFFE0: FF FF FF FF B4 80 BC 80   FF FF FF FF FF FF FF FF | ................
    0xFFF0:       ------- b l a n k ----(all 0xFF)-------

  • Chester Gillon said:
    The attached 4540.ISR_causes_download_error.zip is a Visual Studio 2010 project which shows the problem, by calling the MSP430.dll with the minimum set of flash programming to show the problem. It only attempts to program:

    a) Bytes 0xB4, 0x80, 0xBC, 0x80 at address 0xffe4

    b) Bytes 0xAC, 0x80 at address 0xffea

    If the test program is modified to change the order of programming, so that the 2 bytes at address 0xffea are programmed followed by the 4 bytes at address 0xffe4 then no verification failures are reported:

    ISR_causes_download_error.exe
    USB I/F 0 COM11 enabled status = 0
    FET FW version = 3.3.1.3
    Found device MSP430F12x2/F11x2
    Erase device main memory
    Programming 2 bytes at address 65514
    Programming 4 bytes at address 65508

    And FET-Pro430 confirms the correct data has been programmed:

    ========== Main Memory Segments  0xE000 - 0xFFFF ======

    0xE000:       ------- b l a n k ----(all 0xFF)-------


    0xFFE0: FF FF FF FF B4 80 BC 80   FF FF AC 80 FF FF FF FF | ................
    0xFFF0:       ------- b l a n k ----(all 0xFF)-------

  • Chester Gillon said:
    If the test program is modified to change the order of programming, so that the 2 bytes at address 0xffea are programmed followed by the 4 bytes at address 0xffe4 then no verification failures are reported

    That's very odd. Thanks for writing the test code and doing the tests.
    It' sstill unclear whether it is a problem on the target seide (problems with the flash controller?), the FET (the Flash write function inside the FET or the injected flash write code) or the DLL (API problem, reporting an error where there is none).

    BTW: congratulations for joining the ranks of us gurus.

  • I got a report saying that the "Fast Verification" in CCS is not returning an error, so this suggests that programming works, but the following read is returning garbage. There was a similar issue, where in some tests a specific address was reading wrong values after programming.

    If anyone that can reproduce the issue happens to use the open source version, can you try modifying the template database entry for the 1232 to disable quick memory reads by changing:

    typedef MSP430F12xx<
        MSP430F1232, MSP430F12x2_Match,
        FunctionMappingNone,
        Size<0x2000>, Offset<0xE000>
    > MSP430F1232_type;

    to

    typedef MSP430F12xx<
        MSP430F1232, MSP430F12x2_Match,
        FunctionMappingNone,
        Size<0x2000>, Offset<0xE000>,
        MSP430F12x_Features
    > MSP430F1232_type;

**Attention** This is a public forum