| Author |
 Topic  |
|
|
i5uxjal
Italy
5 Posts |
 Posted - 12/03/2005 : 09:17:13
|
i tried to program pic 16f877 with a file .hex and .bin
the problem is that the eeprom data is in another location 4200
and not to 4000.
second problem the data of eeprom is writed shifted of one byte.
example
data to eeprom is 11 22 33 44 55
when writed
in the pic is
11 00 22 00 33 00 44 00 55
i think some error in use of the bin and hex file.
i have two other programmer and with the same file all work fine.
could you help me to fix
hello Alfredo |
|
| Reply #1
ZLM
2945 Posts |
Posted - 12/05/2005 : 23:56:31
|
I think for the data location in windows's buffer should be fine, as long as it can program to the right location of the chip.
Also, for the code, the TopWin is not using the 14bit code format, it uses double bytes to store the code. also, the stores LSB byte first. This is why the code "11 22 33 44 55" become "11 00 22 00 33 00 44 00 55 00".
Again, as long as it can program the chip correctly, the format of display does not matter.
This does not need to be fixed. |
 |
|
| Reply #2
i5uxjal
Italy
5 Posts |
Posted - 12/06/2005 : 14:22:51
|
i think that topwin not respect the microchip specification.
i had tried to program pic16f84 and the result is the same , bad eeprom program.
i had tried to program with many files .hex found in the web ,
all have the same problem with top win ,
if i program the chip with other programmer all data go in the rigth location.
you tell tath no need fix , but no need fix if you read a pic than you copy to another pic ,
but if you read the pic than you distribute a file the other user cannot program the pic with other programmer because the eeprom data is in other location.
i hope in future fix for microchip .
hello Alfredo
|
|
|
| Reply #3
ZLM
2945 Posts |
Posted - 12/06/2005 : 17:27:00
|
It seems TopWin is correct for the data started from 4200H for 16f877 and 16F84.
I tried on the Microchip's MPLAB IDE v7.21. I think this software should be the standard and all of us should follow it.
I selected device 16f877, and then manully entered the code :1AAA 1BBB 1CCC, data: 11 22 33 44 55, config bits: 3FF2, user ID: 12345. Then save those into a hex file.
I opened the hex file by notepad, and it shows:
Code section started from 0000H:
:10000000AA1ABB1BCC1CFF3FFF3FFF3FFF3FFF3F38
:10001000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3FF0
....
Data section started from 4200H
:1042000011002200330044005500FF00FF00FF00B2
:10421000FF00FF00FF00FF00FF00FF00FF00FF00A6
....
Config bit started from 400EH
:02400E00F23F7F
ID started from 4000H
:0840000000000100230045004F
..
I also tested 16F84 from MPLAB IDE, the result is same: Code started from 0000H, Data goes 4200H and config bit goes to 4000H.
I agree with you that if the hex file format is different, then you can not pass the hex file to other programmers to read correctly.
|
Edited by - ZLM on 12/06/2005 17:43:35 |
|
|
| Reply #4
i5uxjal
Italy
5 Posts |
Posted - 12/08/2005 : 20:57:40
|
First thanks for the kind answer.
In order to become simpler we consider only pic16f84.
You wrote " I think this software should be the standard and all of us should follow it. "
yes because it should be a standard , the problem with top win really exist.
i have compiled a short code + eeprom data.
for strange reason mplab use for eeprom address 4200 and not 4000.
but other programmer know this and probably they convert the address.
if you try to program 16f84 with an hex file with data at 4200 address , the eeprom will remain clear , because the pic not have eeprom at 4200.
this is the first problem.
i confirm the second problem
with a file hex compiled by mplab ( you say a standard) the data is writed as word and not as byte into the pic .
but if i load a file .hex , than manually I insert a data in the window at 4000 the eeprom is programmed ok.
then if i read the pic and save to file the file will be writed with the eeprom data at 4000 and this is not standard for pic file.
the file is incopatible with all other programmer and mplab standard.
my idea is :
topwin read file at 4200 and just try to program at 4200 address , this shold be correct , but because for strange reason microchip need conversion for good programmation , top win when program the pic should make the correction of address and write byte and not word.
excuses me for my bad English but i hope you understand me.
please try to program pic16f84 with sample file with eeprom data , then try to read the eeprom data .
you will see no data into eeprom .
hello Alfredo
|
|
|
| Reply #5
hartog
USA
4 Posts |
Posted - 12/18/2005 : 20:15:46
|
I am having this same problem with the PIC16F84A. Much of what I say here was said by the previous poster "i5uxjal".
For MPLAB to simulate the data EEPROM initialization correctly, you have to declare your EEPROM data at 0x4200 with an "org 0x02100" statement. This seems to be the standard convention. However, when the resulting HEX file from MPLAB is loaded in TopWinEn and programmed into a PIC16F84A with a TOP2004, the data EEPROM does not appear to be programmed.
I compiled some code to write the entire data EEPROM with a known sequence (data=addr for addr=0x0 to 0x3f) from within the PIC16F84A program itself. After running the program, I read the PIC16F84A on the TOP2004 programmer. What I found is that the EEPROM contents are reported by TopWinEn 0x4000 -- not 0x4200. As with the prior poster, the data seems to be read out in bytes, not 16-bit words. For example, I expected to see 00 00 01 00 02 00 03 00 ... for the first line. Instead, the first line is reported by TopWinEn as 00 01 02 03 04 ...
It seems to me that the data EEPROM contents cannot actually be mapped at 0x4000 because that conflicts with the location of the "ID" bytes at 0x4000 to 0x4007 (or PIC word addresses 0x2000 to 0x2003). Also the configuration word seems to be stored at 0x400E to 0x400F (or PIC word addresses 0x2007). For these reasons, I can't just move my EEPROM initialization to 0x4000 -- it is overwritten my the configuration word.
It would seem that the PIC16F84 (and probably all of the PIC16 series) expects some kind of special recognition and treatment by the programmer for the mapping of the data EEPROM.
I don't know what the proper fix is; however, I'm sure that it involves an update TopWinEn of some sort. Other programmers can read the HEX file from MPLAB and program the PIC16F84A data EEPROM correctly, so the information must exist in the HEX file to program the data EEPROM properly.
Do you know if TopWinEn is updated regularly? Are they responsive to these types of problems? How would we even report this problem to them? I don't even know the link to the manufacturers web site.
--Scott |
|
|
| Reply #6
hartog
USA
4 Posts |
Posted - 12/19/2005 : 12:49:04
|
I have looked at this some more, but I am still completely mystified.
It appears to me that the HEX file produced by MPLAB is completely correct (or at least correlates to Microchip's PIC16F84A programming Spec); however, the TOP2004 programmer (using TopWinEn version 1.479) does not program (or apparently even read) the data EEPROM of the PIC16F84A correctly. It apparently conflicts this range with the HEX address range used for the config and ID information.
Any help would be appreciated. Is there any mechanism for submitting these problems to people that can actually correct the situation?
Has anyone successfully programmed the data EEPROM of a PIC16F84A with the TOP2004 programmer? If so, would you please send me the HEX file used so that I can see how it was accomplished?
--Scott
The spec DS30262e from Microchip (http://ww1.microchip.com/downloads/en/DeviceDoc/30262e.pdf) describes the programming of the data EEPROM for the PIC16F84A. It states flat-out that the hex file entries for the data EEPROM are from 0x2100 to 0x213F. When I look at the HEX file produced by MPLAB, I see the following lines at the very end of the file...
:1007F000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F09
:104200000000C9008000FF009B00AE00FF00FF001F
(omitted HEX lines 4210 thru 4260 for brevity)
:10427000FF00FF00FF00FF00FF00FF00FF00FF0046
:02400E00F23F7F
:08400000FF3FFF3FFF3FFF3FC0
:00000001FF
I decoded these lines as shown below.
I have converted the addresses from byte addresses to 16-bit word addresses (actually 14-bit word addresses) to correlate to the addresses used in the PIC documentation.
:1007F000FF3FFF3FFF3FFF3FFF3FFF3FFF3FFF3F09
0x03f8: 3FFF <-- last HEX line of normal program memory
0x03f9: 3FFF
0x03fa: 3FFF
0x03fb: 3FFF
0x03fc: 3FFF
0x03fd: 3FFF
0x03fe: 3FFF
0x03ff: 3FFF
:104200000000C9008000FF009B00AE00FF00FF001F
0x2100: 0000 <-- first HEX line of EEPROM data
0x2101: 00C9
0x2102: 0080
0x2103: 00FF
0x2104: 009B
0x2105: 00AE
0x2106: 00FF
0x2107: 00FF
(omitted hex lines for 0x2108 thru 0x2130)
:10427000FF00FF00FF00FF00FF00FF00FF00FF0046
0x2138: 00FF <-- last HEX line of EEPROM data
0x2139: 00FF
0x213a: 00FF
0x213b: 00FF
0x213c: 00FF
0x213d: 00FF
0x213e: 00FF
0x213f: 00FF
:02400E00F23F7F
0x2007: 3FF2 <-- config word
checksum = "7F", calc_checksum = 0x7f
:08400000FF3FFF3FFF3FFF3FC0
0x2000: 3FFF <-- "ID" information
0x2001: 3FFF
0x2002: 3FFF
0x2003: 3FFF
:00000001FF <-- end-of-file record
|
|
|
| |
Topic |
|
|
|
bad eeprom program with topwin and 16f877
Forum Locked
