MSP430, CCS 5.5, save\dump memory to hex file

I got the hex430 to produce an Intel hex file by using the -o=filename option. This is not shown as a necessary option. I figured it would just take the input filename and use the .hex extension as an output file.

The usage line when running hex430.exe -h should be changed from:

hex430 [-options] filename        to:

hex430 [-options] -o=filename_out filename_in

Anyway, now I want to verify this newly created .hex file with the contents of the flash in the MSP430. BUT, guess what? There is no option (in CCS 5.5) to compare against a .hex file. The choices are: .out, .asf, and .x.

How can I verify my .hex file against a programmed part in CCS 5.5?

Regards,

Jim

I downloaded the MSP430 Flasher. However, it does not seem to have a "verify" function so that I can verify my programmed part against a .hex (or TI-TXT) file reference.

Further, for programming, the "-w filename" option indicates that both .hex and .TXT are supported. However, the "-r filename" option for reading memory to a file does NOT indicate that both file types are supported.

Additionally, it does not make clear that it will key off the file extension of the command line argument as the indicator for file type. But, this is somewhat expected behavior I guess.

However, that still leaves me unable to verify my saved memory .hex file against a known correctly programmed part. The memory was saved to a .out file and then converted to a .hex file. I need to verify this file before it goes to manufacturing.

Regards,

Jim

OK, so I tried to take a different tact. I programmed my target board with the generated hex file from the memory dump. I figured I would then go into CCS 5.5 and compare the .out file (as CCS does not allow selection of .hex for compare) against the part. In this manner, I can verify that the dump\convert was successful.

However, CCS 5.5 does not have an option to verify a limited memory range only. Therefore, the compare fails very quickly because the part is programmed with combination of boot loader and application. CCS 5.5 projects are EITHER boot OR app, so if fails when compared against a combination file.

This is crazy. Verifying .hex (TXT, S-rec, etc) is such a fundamental part of dealing with flash memory I expected this to be a simple turn-the-crank operation. Verify parts-to-files, files-to-parts, and address-range-limited capability should be simpler.

I may have missed something and merely having a "brain cloud". I hope that is the case; It has happened before ;-).

Regards,

Jim

Jim,

MSP430 Flasher might actually be a better choice in this case, since the CCS "Save Memory" command does not allow you to save directly to a hex format. I haven't personally used MSP430 Flasher but according to this wiki link, you should be able to first program the code to the part (either using MSP430 Flasher or CCS), and then read out the memory from the device into a TI-TXT or Intel hex file using MSP430 Flasher. Can you do this and then compare this hex output with the hex output from a known good part? I imagine the comparison itself would need to be done with some external tool.

The MSP430 Flasher tool comes from the MSP430 team rather than the CCS team, so if you decide to use that tool and have further questions on its usage, I would suggest posting those to the MSP430 forum.

Jim,

CCS5.5 has a 'Verify Program' option; This allows you to compare the data from a program file (or hex file) with the data on your device.

In the menu, choose 'Run -> Load -> Verify Program'.

Even though the default file types in the File Browser are *.out, *.axf, and *.x, you should be able to change it to "All Files" and choose your .hex file for verification.

With this, you should be able to verify the bootloader and applications separately and make sure it is programmed (or converted) correctly with the data on the device.

Btw, we also support performing the verification step using command line (using CCS or UniFlash), so I can give you more information on this if it is something you want to integrate into your work flow instead of going through the GUI.

Anyways, please try this out and let me know if this fits your requirements.

Thanks,

Ricky

Hi Ricky,

Thanks for your reply, I have been at this all day.

You are correct, I was able to compare against a .hex file with your suggestion of selecting "All Files", even though it is not shown as an expected file type.

However, the plot thickens. I had reprogrammed my boot loader with CCS and then downloaded the application with the serial port, so I have a clean start. I compared the file and it failed at the second byte (0x8001). As this file was from earlier experiments, I decided to create a new hex file from a memory save\dump.

I saved memory from 0x8000 to 0xFFFF, my area of concern. I can only save it to a .out file if I want to end up with a .hex file, which I did. Then I ran "hex430.exe -i -o=filename_out memdump.out". The file FAILS COMPARE! Looking at it in the editor, it is not even close. This whole process seems to be broken.

So, I decided to use the MSP430Flasher to save\dump memory. It can't access the FET430 so I need to exit my debug session in CCS... OK. Then, it doesn't like the firmware version in the FET430. It needs to program it... OK. I have programmed this thing at least 8 times today between CCS and MSP430Flasher.

So, now I can download directly to a hex file (even though the MSP430_Flasher_Doc.pdf doesn't explicitly state that this is supported with the "-r" option. Using the command line "MSP430Flasher.exe -n [mem_dump.hex,MAIN]".

Then back to CCS, reprogram the FET430, compare the file. The file FAILS COMPARE! So, looking at the hex file in the editor, it starts at address 0x2100 and goes to 0x7ff0 which I believe is not valid memory for my part. I deleted that portion of the file so that it starts at address 0x8000. I perform the verify and IT SUCCEEDS!!.

This leaves several key points on file verify deficiencies in the TI tools:

- The CCS memory save and convert is BROKEN

- Switching between Flasher and CCS is cumbersome and time consuming

- The verify tools do not allow the user to specify a range

- The download tool in MSP430Flasher does not allow the user to specify a range

- CCS does not list .hex or .TXT as default types in the compare menu

- The document MSP430_Flasher_Doc.pdf does not fully describe files supported for the "-r" option

- MSP430Flasher did not acquire the correct memory range even though the part is indicated on the command line.

- MSP430Flasher does not have a verify-only function. Verify is only part of a programming cycle.

- The command line help for hex430 should be "hex430 [-options] -o=file_dest file_src" because it does not produce any default destination file without -o, which really means it NOT an option.

- On a side note, the memory save to .dat does not allow for address information to be inserted with the file (at least I haven't found it). And it does not support columns. Every mode that I have used is just a long column 1 document which is not the most user-friendly.

I appreciate your suggestion as that did get me over the hurdle but was really one small part of the puzzle. Please make the process of comparing files-to-parts, parts-to-files, files of many types, and user controlled address ranges available and simpler.

I have several products that I have to support in this manner. They were migrated over from Freescale S08 parts to MSP430. However, I must say that this process was MUCH simpler and flexible on the S08 parts using the older version 5.x to 6.x Code Warrior tools (ancient stuff). I expected the new Java wiz-bang CCS tools to be a breeze but it is not.

Regards,

Jim

Hi AartiG,

Thanks for the reply.

I was already using MSP430Flasher in conjunction with using CCS to attempt to verify the file when you replied (see my prior post). There are problems with MSP430Flasher as well.

- It does NOT have a stand-alone verify function, it only verifies as part of a programming cycle.

- It put invalid memory into the hex file even though the part is indicated as a command line argument.

- It does not let the user specify a memory dump range.

- It does not let the user specify a verify range.

- Command line help does not indicate a destination file spec is required (see previous post)

- The user guide does not clarify the file types supported with -r option (see previous post)

In the end, I had to use MSP430Flasher and CCS in conjunction which is cumbersome and slow as the debug session in CCS has to be ended and the FET430 has to be reprogrammed for Flasher. Then it has to be reprogrammed again for CCS to do the compare. Quite convoluted just to save memory and verify it.

Regards,

Jim

Here is another annoyance when working with .hex files in CCS. I might as well suggest this while it is all fresh on my mind from this endeavor.

If I want to load a .hex file in CCS, I cannot select "Browse Project". That only works for .out files.

So, instead, I have to browse the files system and use the "All Files" filter because .hex & .TXT are not part of the standard filtered file set. This is useful for when the hex\TXT file is indeed outside of the project folder set. But, when the hex\TXT files are within the folder set, this could be easier.

I keep any hex\TXT files in the Debug directory with the built .out file (all checked in revision control). Two solutions could make this easier:

1) There should be a shortcut button for the files system browsing to take you directly to the project directory set. Best yet, where the .out file is (in my case anyway).

2) Allow "Browse Project" to recognize hex\TXT files. This could be optional with a check box on the browse window.

And of course, change all file filtering to include hex\TXT files as a default.

Regards,

Jim

Jim,

Thanks for the feedback. I will give my view on the CCS related topics. For the MSP430 Flasher feedback, you might need to post on the MSP430 section to get better visibility as Aarti suggested.

1. MSP save and convert is broken

- Can you try saving the memory to an .out file and doing the verification without the convert step? If this passes, this means that there is something wrong with converting the file from .out to .hex using hex430. I'm not too familiar with this tool, so I need to look up the right contact for this tool if the problem is with hex430.

2. Specify range for verify

- As you noticed, this is not supported currently. I will see if we can add this for future releases. In the mean time, you can control where you are verifying by the memory range you are exporting/saving.

3. Default file extension type

- I'll ask the IDE team to look into adding additional file extensions that we support. The problem is that we support a lot of different file types, so I'm not sure if we can list them all. Also, the file extension itself does not matter as much as the content of the file (header information). This is how our program loader determines the file type, meaning users can load a file with any extension they want, as long as it is in the correct format.

4. Using Hex files in CCS

- Can you let me know your use case for using hex files within CCS?

I'm thinking you can stick with .out files for debugging purposes within CCS, and convert them to hex formats when they are ready for production, etc. In this case, you can move to a standalone Flash Programming tool like UniFlash that has a simpler GUI as well as command line support for loading and verifying you programs.

Thanks,

Ricky

Hi Ricky,

1. MSP save and convert is broken

The .out file verifies correctly. The Intel hex file does not. I am dumping and verifying 0x8000 - 0xFFFF in my test.

Further, the failure message when the hex file fails, while may be technically correct on some level, is misleading. The error is:

File C:\<dir\filename>.hex: a data verification error occurred, file failed to load.

The latter part, "file failed to load", was leading me to believe that file access was a problem, ie: disk operations. I can see how the terminology is correct as the file is being loaded into memory for compare. It is not being loaded into the part though. It's a very small semantic but I figured that I should mention it. I would just truncate the message to a data verification error.

3. Default file extension type

I can see that there is a limitation to what file types can be show on the filter drop down box. But, the user really has no way (in the work flow, maybe it's in the help file somewhere) what files are supported without trial-and-error which is not refined or user friendly.

I would suggest putting a help button [? question mark button]  or a button with "File types" on it. The user can then check, and be aware, of the supported file types. This would, of course, require a custom file browser dialog box. But, it needs what it needs.

Maybe this file type box, can be a radio button list so the user can customize the file filter list for their needs. Maybe that's overkill, I don't know.

4. Using Hex files in CCS

Using a separate program sounds simple enough. It is doable. However, I was using the MSP430Flash which does not support verification only. Verification in only part of a programming cycle. Perhaps other tools, such as UniFlash have better features and control.

To the usage case, in our lab environment, I get asked often to program a board for others, Compliance Engineering, SQA, test setups, verification builds, and more. Hex files are the deliverable format. To use a separate tool, I have to end my debug session, launch the other tool, let it program the FET430 to compatible firmware, program the board, go back to CCS, let it program the FET430, and start the debug session again. Again, as long as the alternate tool has the features needed, it is doable.

I went back and looked at CCS 3.3 for the C2000. I thought that it allowed loading and verifying of hex files.It does allow a save and load of hex files but not verification. The load\save is limited and under the "File menu". I guess because we do not provide a combined boot & app file to manufacturing on the larger parts, I never noticed the lack of support for that.

So, that begs the question, why should the new MSP430 tools provide that function? I can't say that I am in a strong position to say it should. I can only say that on the smaller parts, we do provide a combined file for manufacturing and that when these project where Freescale S08 based, the tools supported this verification. So, while a made a strong argument last week for this feature in CCS5\6, having the weekend to look further at CCS 3.3, perhaps it is expected to use an alternate tool. The question is, what tool will do what I need? I have not tried (or heard of) UniFlash. A quick Google and I see it is from TI. I will give it a try.

The FET430 is affordable, so I could get a second one and program parts on an alternate PC. This would eliminate the interruption of the debug session and reprogramming of the FET430. Its fixing the workflow at the MACRO level but it works.

5. MSP430Flasher

If the UniFlash is tool to use, then I guess the feedback to the MSP430Flasher team isn't necessary unless they just want to make a more useful tool. It was suggested a couple times that I post over there for their portion. If your team feels this is feedback or features they are interested in, I will leave up to internal TI to post to the other forum. I have spent enough time "Programming SQA" and trying to get the program\verify done. I have a couple of other number 1 priorities to work on. Wait a minute... everything is always #1 ;-)

Regards,

Jim

Jim,

Thanks again for the feedback.

It looks like you confirmed that the hex430 utility is the step that is causing the verification error. Unfortunately, I don't have any information on how this tool was implemented, so I will need to find the right contacts to debug this. For reference, can you give me the command and arguments you used for hex430?

The "file failed to load" part of the error message is due to the fact that our Program Loader handles both loading and verifying and therefore this is a generic error message it displays. The ideal error would be that it tells you it is an verification error, as well as the failing address and expected versus target data.

I'll talk to the IDE team to see what we can do to handle file extensions better in CCS.

Thank you for providing your use case for hex files. Since you are in the CCS environment already in your case, it is ideal to be able to do everything in CCS instead of moving to UniFlash or MSP430Flasher. UniFlash provides bascially the same functionality as CCS, without the debugger, but with a more streamline GUI for loading programs and performing Flash operations. You can try it out if you have time for future references.

Thanks,

Ricky