The programming time between .hex and .txt with MSP430 Flasher

Hi Nomoto,

I would have to confirm with our tools developers about this, but it makes sense to me because the Intel hex format is much more complex and includes record info, checksums, etc at every line, whereas the TI .txt file format does not (.txt has just address when a new block starts, and then just code - very lightweight). This means there'd be more time parsing the file and checking the checksums on the .hex format I think. However, I will ask as well.

Regards,

Katie

Hi Nomoto,

I spoke to one of our tools developers, and he wanted to know a little more information to help see if your number makes sense or not:

• Is the 52k binary programmed in one continuous block, or are there many different sections that are programmed to different locations of memory?
• Which version of the MSP430Flasher software are you using?
• What parameters are being used to call msp430flasher.exe
• What's the target MSP430?

Regards,

Katie

Hello Katie-san,

Thank you for your reply.
I'll answer the following questions which I could confirm to my customer.

 

Katie Pier said:

• Which version of the MSP430Flasher software are you using?

ver1.3.3

Katie Pier said:

• What parameters are being used to call msp430flasher.exe

MSP430Flasher.exe -n MSP430F5359 -w ".hex directory" -v -z [VCC=3000, RESET]

Katie Pier said:

• What's the target MSP430?

MSP430F5359 in BGA package

 

Best Regards,

 

Nomoto

 

Hello Katie-san,Thank you for your reply.
I can understand that lots and lots of separate small section makes the programming time longer.
Thank you for your close support again.Best Regards,Nomoto

Yusuke Nomoto said:

I can understand that lots and lots of separate small section makes the programming time longer.

BTW, if you want, you can send me txt / hex file to try it with my flasher. And I can post results here.

Because .txt / .hex file is my customer's confidential file, I can't get it.
Thank you for your kind suggestion, however I can't share it.

I don't care about contest, because it will not be executed on my target device. You can replace original data with random numbers, just leave address section/blocks untouched.

Some small difference in flashing rate regarding continuous / many small sections can be, but don't see any reason (from my point of view and my flasher design) for txt / hex rate difference.

D:\msp430>flash -p com14 -f test_msp430f5510.txt -e -ws -v

File: "test_msp430f5510.txt"
Address: 08000  Words: 16384
Size: 32768 bytes

Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
0  91   OK   3081  2106  10   10  B7A50951 0A00 1100

Erase

Write Smart
Time: 204 ms  Speed: 156,4 KB/s

Verify
Time: 159 ms  Speed: 200,9 KB/s

Release Device

Total Time: 500 ms

D:\msp430>flash -p com14 -f test_msp430f5510.hex -e -ws -v

File: "test_msp430f5510.hex"
Address: 08000  Words: 16384
Size: 32768 bytes

Get Device
# JTID Fuse Device Core Hard Soft LotWafer DieX DieY
0  91   OK   3081  2106  10   10  B7A50951 0A00 1100

Erase

Write Smart
Time: 204 ms  Speed: 156,6 KB/s

Verify
Time: 159 ms  Speed: 200,9 KB/s

Release Device

Total Time: 500 ms

D:\msp430>  

Assuming '52k' means the code size and not the file size (since HEX format has more overhead per binary byte, this would mean less code to burn if this were the data file size), I try to make a guess:
In TI TXT format, you usually have one address and then as much data as there is contiguous data to write. This means a simple parsing algorithm can do large write blocks.
In iHEX format, each text file line has its own start address and checksum. So a simple parsing algorithm can only write one line (= 16 bytes usually) at a time. Which leads to much programming overhead.
This would correspond to the observed difference in programming time.
The time for doing checksum tests etc. Is negligible, unless you parse the files with an old IBM PC/XT or something similarly slow. :)

Hard to believe that .hex files process longer than .txt files, since today's processing power parses a .hex file in a time that is negligible compared to flash time

Depends on where you parse it, on a GHz PC or on the target MSP itself :)
And how 'straight' the algorithm is.

Can anyone say how I can load the firmware through the MSP430.Flasher? How does it use HEX or TXT to flash the MSP?

Hi CaEngineer,
Let's try to keep everything related to your MSP430Flasher issue in your thread with Akash here: e2e.ti.com/.../1753600 It will be easier for people to follow along.
-Katie