• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 2467 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Issue with Uniflash

Paul Claessen
Prodigy 90 points
Other Parts Discussed in Thread: UNIFLASH, MSP430FR6989

Uniflash issue

I have two MSP430FR6989 eval boards. I want to copy the image from one board onto the other.
First I use Uniflash in 'Memory' mode to export the memory in COFF format.
Uniflash (version 4.3.0.1802) writes the file to disk (it's only 64K even though I'd ask to get the full 128K, so I assume there's some compression involved).
I then switch boards, (automatically detected by Uniflash) and try to flash the COFF file.
Once I hit 'Load', Uniflash shows a splash screen that says "Load Program, Please Wait... Executing Startup Scripts: MSP430" ... and then hangs. Cancel doesn't work.
It DOES generate a log file ...

My first question is: is this the correct procedure to copy an image from one board to another, and if so .. what would cause this to make Uniflash hang?

The logfile contains info from various attempts .. and I seem to get different log info in different attempts.
The latest attempt wrote the following to the log file:


0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [control] Control frame received with opcode 8
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [control] Control frame received with opcode 8
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [frame_header] Dispatching write containing 1 message(s) containing 2 header bytes and 2 payload bytes
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [frame_header] Header Bytes:
[0] (2) 88 02
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [frame_payload] Payload Bytes:
[0] (2) [1] é
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [frame_header] Dispatching write containing 1 message(s) containing 2 header bytes and 2 payload bytes
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [frame_header] Header Bytes:
[0] (2) 88 02
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [frame_payload] Payload Bytes:
[0] (2) [1] é
0x00001900 7042746 3 WBSKT E: [2018-05-30 13:34:25] [error] handle_read_frame error: websocketpp.transport:7 (End of File)
0x00001900 7042746 3 WBSKT E: [2018-05-30 13:34:25] [info] asio async_shutdown error: system:10054 (An existing connection was forcibly closed by the remote host)
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [disconnect] Disconnect close local:[1006,End of File] remote:[1001]
0x00001900 7042746 3 WBSKT E: [2018-05-30 13:34:25] [error] handle_read_frame error: websocketpp.transport:7 (End of File)
0x00001900 7042746 3 WBSKT D: [2018-05-30 13:34:25] [disconnect] Disconnect close local:[1006,End of File] remote:[1001]
0x00001900 7042747 3 WBSKT E: [2018-05-30 13:34:25] [info] Error getting remote endpoint: system:10009 (The file handle supplied is not valid)
0x00001900 7042747 3 WBSKT D: [2018-05-30 13:34:25] [fail] WebSocket Connection Unknown - "" - 0 websocketpp:26 Operation canceled
0x00001900 7042747 3 WBSKT E: [2018-05-30 13:34:25] [info] asio async_shutdown error: system:10009 (The file handle supplied is not valid)
0x00001900 7042747 3 WBSKT E: [2018-05-30 13:34:25] [info] handle_accept error: Operation canceled
0x00001900 7042747 3 WBSKT E: [2018-05-30 13:34:25] [info] Stopping acceptance of new connections because the underlying transport is no longer listening.
0x000040C8 7042769 3 LIB C: dlclose( 0F2A0000 )
0x000040C8 7042769 3 LIB R: dlclose( 0F2A0000 ) = 1
0x000040C8 7042769 3 MSP C: MSP430_Close( FALSE )
0x000040C8 7102767 3 MSP R: MSP430_Close( FALSE ) = 0
0x000040C8 7102767 3 MSP C: dlclose( 04460000 )
0x000040C8 7102767 3 LIB C: dlclose( 04460000 )
0x000040C8 7102767 3 LIB R: dlclose( 04460000 ) = 1
0x000040C8 7102768 3 MSP R: dlclose( 04460000 ) = 1

  • 0
    TI__Guru**** 465811 points

    Hi Paul,

    Paul Claessen said:
    First I use Uniflash in 'Memory' mode to export the memory in COFF format.
    Uniflash (version 4.3.0.1802) writes the file to disk (it's only 64K even though I'd ask to get the full 128K, so I assume there's some compression involved).

    I think this is a bug with the Export Memory feature in UniFlash. There does not seems to be any compression. What I have observed with MSP430 devices is that when exporting a binary file, only half the number of bytes specified is exported. The reverse appears to be true when exporting COFF format - double the amount of bytes appears to be exported.

    Paul Claessen said:
    Once I hit 'Load', Uniflash shows a splash screen that says "Load Program, Please Wait... Executing Startup Scripts: MSP430" ... and then hangs. Cancel doesn't work.

    I don't see the hang however. But thanks for the log. I will get them analyzed and keep y ou posted

    ki

  • 0 in reply to Ki
    TI__Guru**** 465811 points

    Ki-Soo Lee said:
    I think this is a bug with the Export Memory feature in UniFlash. There does not seems to be any compression. What I have observed with MSP430 devices is that when exporting a binary file, only half the number of bytes specified is exported. The reverse appears to be true when exporting COFF format - double the amount of bytes appears to be exported.

    I filed a bug for this. Tracking ID: UNIFLASH-1061

  • 0 in reply to Ki
    TI__Guru**** 465811 points
    Forgot to ask - are you using UniFlash in the Cloud or Desktop?

    Thanks
    ki
  • 0 in reply to Ki
    Prodigy 90 points

    Ki,

    I'm using Uniflash (version 4.3.0.1802) desktop version, on WIndows 7.

    My observation with reading memory from an MSP430FR6989 is different from yours, in that BOTH bin and coff files write only half the bytes of the requested length.
    My earlier attempts were with coff files.

    So, just now I tried with a bin file. Requested 128K and only got 64K. So I then requested 256K and got 128K (I also tried asking 512K and got 256K, even though the device doesn't have 256K memory, so I suppose it wraps).

    Then I tried programming my 2nd board with the 128K bin file. Unlike my effort with a coff file, I didn't see a hang, but Uniflash almost immediately returned with an error message:

    [5/31/2018, 8:11:27 AM] [ERROR] MSP430: Trouble Writing Memory Block at 0x0 on Page 0 of Length 0x7ff0: Could not write device memory
    [5/31/2018, 8:11:27 AM] [ERROR] MSP430: File Loader: Verification failed: Target failed to write 0x00000

    Note the length! (A little less than 32K!)

    I tried this again, just to sure .. with the same file, and got the same result!

    Then I tried a third time, but now using the 64K bin file, and I got the exact same error again (lenght 0x7FF0)

    I can attach the log file that was created for those three attempts.

    I guess the exercise for the person going to look into this and (hopefully) fix it, is simply this: Using Uniflash, copy the contents of one board's memory to a file, then program a different eval board (same proc, etc), with that file.

    If that works, please explain how it's done. If they run into the same problems I'm having (this SHOULD be easy!!), then I hope they can fix it, and let me know in when it's fixed (and in which version).

    Thanks for your much appreciated support!

    ~ Paul



  • 0 in reply to Paul Claessen
    Prodigy 90 points
    I actually got the image copy to work now!

    The problem was the start address.

    When I looked at 'Settings and Utilities' in Uniflash, I noticed it mentioned a start address of 0x4400 and high address of 0x23FFF. (which is a 127K memory region).
    When I then read the source board's memory, from 0x4400 for 127K * 2 length, to a binary file, and then flashed that file to the new board, also at start address 0x4400, it all worked just fine. The thus transferred image now runs fine on the target board.

    Remains the issue with only reading half of the specified bytes, but a ticket was filed for that already.

    ~ Paul