Jump to content
Sign in to follow this  
Brad

Wrong _config And _eeprom Addresss In Hex File

Recommended Posts

Hi,

 

Compiling to PIC16F886 with SourceBoost V6.97 Beta 2 or V6.96 on a Windows XP machine. Using the following preprocessor directives:

 

#pragma DATA _CONFIG1, _DEBUG_OFF & _LVP_ON & _FCMEN_OFF & _IESO_OFF & \
				   _BOR_NSLEEP & _CPD_ON & _CP_ON & _MCLRE_OFF & \
				   _PWRTE_ON & _WDT_OFF & _XT_OSC
#pragma DATA _CONFIG2, _WRT_OFF & _BOR21V

#pragma DATA _EEPROM, \
0xCFF9, 178, 155, 138, 124, 113, 103, 95, 88, 82, 77, 73, 68, 65, \
249, 237, 226, 216, 207, 199, 191, 184, 178, 171, 166, 160, 155, 151, \
146, 142, 138, 134, 131, 127, 124, 121, 118, 115, 113, 110, 108, 105, \
103, 101, 99

 

After successfull compile I get the following HEX output:

 

:02400E0001327D

:02401000FF3E71

:10420000F9CFB2009B008A007C00710067005F005C

:10421000580052004D00490044004100F900ED00F3

:10422000E200D800CF00C700BF00B800B200AB006A

:10423000A600A0009B00970092008E008A008600D6

:1042400083007F007C0079007600730071006E00AF

:0A4250006C00690067006500630060

 

It seems to me as if the addresses are incorrect (red text) and the bytes are stored into memory at word (16-bit) offsets (blue text). I can not seem to find a work around to the incorrect address mapping, unless I am mis-reading the HEX file?

Share this post


Link to post
Share on other sites
It seems to me as if the addresses are incorrect (red text) and the bytes are stored into memory at word (16-bit) offsets (blue text). I can not seem to find a work around to the incorrect address mapping, unless I am mis-reading the HEX file?

Memory locations on PIC16 are multiplied by 2 to get the address required in the hex file, so 0x4200 is actually writing to 0x2100.

It appears this all came about because Microchip uses 14 bits for the opcode and the opcode resides at a single address. Intel hex writes 8 bit data to an address, so each microchip opcode location needs two addresses. I will admit it is quite confusing at times.

 

Take a look at the produced .asm and .lst files, they have everything in them in a more readily understandable form.

If you push the .asm file through MPASM you will get the same hex file as BoostC produces.

 

Regards

Dave

Share this post


Link to post
Share on other sites

An oddity I note in that data is that the 0xCFF9 appears at 0x4200 but, if the 4200 gets divided by two to get the reall addres, then one half of that number goes to address 0x4100.5, which clearly isn't going to happen.

 

Are you able to explain what _does_ happen?

 

Thanks

Gordon.

Share this post


Link to post
Share on other sites

GordonS,

An oddity I note in that data is that the 0xCFF9 appears at 0x4200 but, if the 4200 gets divided by two to get the reall addres, then one half of that number goes to address 0x4100.5, which clearly isn't going to happen.

 

Are you able to explain what _does_ happen?

I think you mean that half the number will get written to 0x2100.5, and you are right. Location 0x2100 conists of 16bits, which map to EEPROM locations 0 and 1 when written to during the programming process.

 

Regards

Dave

Share this post


Link to post
Share on other sites

Your content will need to be approved by a moderator

Guest
You are commenting as a guest. If you have an account, please sign in.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoticons maximum are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×