HEX file format?

natsys · Post by **natsys** » Sun May 06, 2007 12:29 am

Hello All ...

First post in this group ... please treat me as not being too experienced!

A while back (years ago) I purchased a PIC training system from Brunning Software. For unavoidable reasons I didn't get down to using it much but have recently pulled it back into service because I've got more time. I also recently purchased Flowcode3, with the expectation that its file output formats would be compatible with the programmer I have. I have tried to take the hex file from a simple program produced by Flowcode3 into the Brunning system, but it fails to assemble. According to information on the Brunning website, this should be possible, but alas not for me so far. I have enquired directly with Brunning Software, and I'm waiting for a response, but in the menatime, I'd like to ask this question here ... are the output file formats from Flowcode3 such that I should expect my fully Microchip compliant programmer to make sense of, or is there some proprietory format involved here?

Thank you in advance for any guidance ....

natsys.

Post by **Benj** » Tue May 08, 2007 9:19 am

Hello

The hex file produced by Flowcode should be compatible with any other PIC programmer. Something Flowcode does do is include the configuration information in the hex file. However this can also be done with Microchips MPASM software compiler.

Post by **Steve** » Tue May 08, 2007 10:14 am

Flowcode produces standard "INHX8M" format HEX files that can be downloaded using a wide variety of programmers. I'm not sure why these HEX files should be incompatible with the ones required by Brunning Software.

I did have a look at their website, but they did not seem to provide any information on their programmer's requirements or capabilities.

natsys · Post by **natsys** » Tue May 08, 2007 10:14 am

Hi Ben .. thanks for your reply.

This confirmation is all I need for now, so I'll wait to hear back from Brunning Software about the issue.

Regards .. Tom.

natsys · Post by **natsys** » Tue May 08, 2007 10:18 am

Hi Steve ...

Thanks for the additional detail, it will prove useful. The only thing I have to go on from the Brunning website is mentioned in the last entry on this page: http://brunningsoftware.co.uk/problems.htm Fingers crossed that it's just me and not some incompatibility!

Regards ... Tom.

Post by **Steve** » Tue May 08, 2007 10:41 am

Tom,

If you have access to any HEX files that have worked with this programmer, you could post the first 4 lines and last 4 lines of it here - this will allow us to see if there is anything unusual about the file formats.

natsys · Post by **natsys** » Tue May 08, 2007 12:44 pm

Steve .... I dug out my old experimental files and converted one, so here you go ...

:020000003128A5
:100008008828820732342C34083406340C340134FE
:10001800023400348207203445347834703465342F
:10002800723469346D3465346E34743469346E34C2
...........
:100108008128900B7F2808008D00030883128C003B
:100118000310860D061E9228013086000B110C086C
:0801280083008D0E0D0E09008D
:00000001FF

I do hope this is what you require. Thanks.

Cheers .. Tom.

Post by **Steve** » Tue May 08, 2007 1:00 pm

Hi Tom,

It could be to do with the embedded config information in the HEX file - this is the only thing different between the files. Microchip recommends that config info is embedded into the HEX file, so it would be surprising that the Brunning programmer did not cope with this config data, but you never know!

Here's the end lines of code typically produced by Flowcode:

Code: Select all

.
.
.

:1000300006058600DF3083120605A000203020046C
:100040008600C830A0000320DF3083160605860036
:10005000DF30831206058600C830A0000320162872
:060060008A110A120B28B0
:02400E00393F38
:02401000FC3F73
:00000001FF

This is code for a 16F88 chip, which has 2 config words. The two lines of code that have this data begin with ":02400E" and ":024010" - you should try manually removing lines like these in your HEX files when using this programmer.

If you use an 18F chip, then this config data will be found in a different location. For example, here are the lines representing config data for an 18F chip (again, these are the 2 lines before the last one in the HEX file):

Code: Select all

:020000040030CA
:0E000000FF020D3E3C9980FF0FC00FE00F4045

Please let me know if this solves your problem.

natsys · Post by **natsys** » Tue May 08, 2007 3:23 pm

Hi Steve ...

I'm not really any further forward but here's the story to date ...

I created a small test program with Flowcode3 for a 16F84A and inspected the hex to see if I could identify any config info. I couldn't, so I copied the hex text file to the programming system, loaded it and tried, as the short piece of advice on the Brunning website says, to assemble it. Well, that's where things stop because it askes me to choose between assembling by low or high byte first, but no matter which I choose, it tells me "the check digits are not correct" and there is no other option but to stop.

Here's the code I've used ...

:02000000522884
:0A0006008F08031D07280800F530DD
:1000100000000000000000000000000000000000E0
:1000200000000000000000000000000000000000D0
:10003000FF3E031D08280000000000000000000033
:100040000000000000000000000000008F0B0728E7
:100050000800FA308F000320FA308F000320FA30B6
:100060008F000320FA308F0003208E0B2928080010
:10007000C0308316810083128D0105300D020318F4
:100080005128831686010130831286008E002920B4
:10009000831686018312860101308E0029208D0A85
:1000A0003D28512883120C108C108A110A1238280E
:00000001FF

I know you are spending time helping me with a problem that may be with someone else's product or even "operator error," so I appreciate your help very much.

I still haven't received a response from Brunning Software so maybe I'll give them a call and see if I can blunder my way through an explanation of the situation.

Cheers .. Tom.

natsys · Post by **natsys** » Tue May 08, 2007 8:38 pm

Hi Steve ...

Now things are getting a bit wierd!

The good news is that I got it all working .... !

The bad news is that it happened only once, with one particular set-up in Flowcode and I can't seem to repeat my success, even by trying the same process I used to get it going ... here's what I did.

First off, I spoke with Peter Brunning himself, but suffice to say, I decided on his advice to try removing lines in the HEX file to see if I could identify a problematic line that the assembler didn't like. There was one, and the line that made the difference was the last one (I think it was :00000001FF) When I removed this line the assembler ran through and gave me a check digit then allowed me to carry on to program the chip. I ran the loaded program and got a dim indication on the LED I was trying to turn on and off.

I thought the clock speed setting in Flowcode might have a bearing on things so I changed it from 19660800 to 4000000 which is 10x the oscillator frequency on pin 15 of the 16F84A in this particular programmer. I re-created the HEX file and after re-programming the chip, that seemed to make the difference because my LED started to flash when I started the program, much slower than I expected but still a success - the timing could get sorted out later I thought.

This was all fine and I thought I was on a winner, but all my efforts to repeat the process since, have failed. One thing I'm noticing now about the HEX files I'm producing from Flowcode, is that where the original start of the files previously had a couple of lines like this:

Code: Select all

:1000100000000000000000000000000000000000E0 
:1000200000000000000000000000000000000000D0

These now seem to be missing from all of my attempts at creating new HEX files. I'm wondering if these are some form of initialisation commands?

When I do use any of the HEX files I'm now producing, without these lines, I find myself back at square one, with the programmer giving the same error message I was getting before I removed the last line of the program. Removing that line now makes no difference.

I'm kind of stuck and going round in circles but I'll press on and see if I can find anything else.

If I have more success I'll let you know.

Cheers .. Tom.

natsys · Post by **natsys** » Tue May 08, 2007 10:17 pm

Another short update Steve ...

It's working again!... this time I hope for good

What I did was ... I changed the clock speed back from 4000000 to 19660800 and I got the two lines back that I said were missing in the HEX files I had been producing (that still puzzles me a bit but maybe you'll understand it.) I then took the file to the programmer and this time I noticed on the last line of the program it showed:

Code: Select all

:00000001F♦

and not as previously

Code: Select all

:00000001FF
♦

So I shifted the End of File 'diamond marker' down to the line below and added the missing F.

This did the trick. I can now re-program the chip at will, and I don't need to delete any lines, as long as I have the EOF marker on the last line by itself and not at the end of the last line of code. I've since created another simple program and run it through this process and I get the same successful result.

The key for me seems to be ... add a carriage return to the .hex text file before taking it to the programmer. This preserves the 'F' in the last line of code and puts the EOF marker in the right place for the Brunning programmer.

Whew! ... I'm wondering what you might be thinking of all this?

Now ... hopefully I can get on with the flowcode3 tutorial ...

Cheers .. Tom.

Post by **Steve** » Wed May 09, 2007 9:30 am

Tom,

Thanks very much for the post - it's great to find a solution to a problem.

I'm sorry you'll have to do this by hand each time. I will ask the makers of BoostC to see if their linker can be altered so that it adds the extra carriage return at the end of the file.

natsys · Post by **natsys** » Wed May 09, 2007 9:34 am

Well Steve ... that would be icing on the cake!

Thank you again. and all the best ... Tom.