[ PIC10F testing ]
> Yes, I think I did.
> But I must look up the archives to see if I said anything about
> *when* I was going to test it... :-) :-)
Heh :)
I've just tested the Wisp628/Easyprog firmware with a 10F202 and created...
an LED flasher... Maybe not the best thing to do with the "world's smallest
microcontroller", but it was the simplest program I could think of at the
time :)
Word of warning: I don't know if this is an MPASM bug or an Easyprog driver
(pic_prog.exe) bug, but the hexfiles MPASM produces - at least for the
PIC10F202 - are rejected by pic_prog - "Address FFF is invalid for this chip"
or something like that. Turns out MPASM is putting the config word for the
chip at 0x1FFF, but Easyprog appears to expect it at 0x07FF. Manually
tweaking the address and checksum in the hexfile produced a hexfile that
pic_prog accepted and programmed into the chip.
> Anyway, with your latest additions/corrections I'm probably going to
> test it "asap". But first I have grab our snowshovel and make sure
> that my wife can get the car out from our parking lot. There was another
> aprox 10 cm snow this night in addition to the aprox 20 cm we
> got yesterday...
Well, at least someone's likely to get snow this year. Last I heard, the
preliminary weather for the 25th (around here anyway) is rain and lots of
it...
Philip Pemberton wrote:
> I've just tested the Wisp628/Easyprog firmware with a 10F202 and
> created... an LED flasher... Maybe not the best thing to do with the
> "world's smallest microcontroller", but it was the simplest program I
> could think of at the time :)
> Word of warning: I don't know if this is an MPASM bug or an Easyprog
> driver (pic_prog.exe) bug, but the hexfiles MPASM produces - at least
> for the PIC10F202 - are rejected by pic_prog - "Address FFF is
> invalid for this chip" or something like that. Turns out MPASM is
> putting the config word for the chip at 0x1FFF, but Easyprog appears
> to expect it at 0x07FF. Manually tweaking the address and checksum in
> the hexfile produced a hexfile that pic_prog accepted and programmed
> into the chip.
None of the addresses you showed are correct. I've programmed 10F206 using
the HEX file directly from MPLAB, and it's supposed to work that way. On
the 10F202 and '206, the config word is at 3FFh, not 1FFFh or 7FFh. I don't
know where you got those other numbers from. You probably have a bad linker
control file. Try using mine. It must already be on your disk at
SOURCE/PIC/P10F202.LINKPIC. Warning: I've only ever tested the 10F series
with real 10F206 parts, but the memory model is supposed to be the same
between the '202 and '206.
There is also a well known bug in MPLAB regarding the __CONFIG directive for
the 10F series. You have to use a DATA directive instead. Here is the
appropriate snippet from one of my 10F206 projects:
;
; Set the static processor configuration bits.
;
config code
data b'111111101111'
; XXXXXXX---XX unused
; -------0---- GP3 is input, MCLR function disabled
; --------1--- code protection disabled
; ---------1-- watchdog timer enabled
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________
> None of the addresses you showed are correct. I've programmed 10F206 using
> the HEX file directly from MPLAB, and it's supposed to work that way. On
> the 10F202 and '206, the config word is at 3FFh, not 1FFFh or 7FFh. I don't
> know where you got those other numbers from. You probably have a bad linker
> control file.
I didn't use the linker - I used MPASM in "HEX Output" (Absolute) mode, not
Object mode.
The addresses came out of the hex file, so dividing by two would probably
give the correct address, i.e. 0x7ff = 0x3FF, 0x1fff = 0xFFF. The 0xFFF was
the address that pic_prog complained about.
> There is also a well known bug in MPLAB regarding the __CONFIG directive for
> the 10F series. You have to use a DATA directive instead. Here is the
> appropriate snippet from one of my 10F206 projects:
Ah, that explains it then. I'll use an ORG and a DATA directive then. I'll
probably switch over to the Embed Inc development environment at some point,
anyway.
Hi !
Regarding the issue of the addresses put into the HEX
files for the config word for the 10F's...
FWIW,
I just built my "beta" of my 10F application
using MPLAB 6.60, relocatable code using the
builtin 10F202.LKR file as-supplied, and using Olins
data directive instead of __CONFIG. Now, I'm no
expert in reading HEX files (they are just "temp"
files for me :-) ), so could anyone see if the adresses
in the HEX file below are correct ?
And, Olin, are you sying that the following
entry in the 10F202.LKR file is incorrect ?
Jan-Erik Soderholm wrote:
> so could anyone see if the adresses
> in the HEX file below are correct ?
No. The HEX file contains FEBh at addresses 1FFEh,1FFFh, which translates
to address FFFh in the PIC. FEBh is correct if you want RB3 to function as
MCLR, code protection off, and watchdog timer disabled. However, the config
word on these chips is at 3FFh, not FFFh.
> And, Olin, are you sying that the following
> entry in the 10F202.LKR file is incorrect ?
>
> CODEPAGE NAME=.config START=0xFFF END=0xFFF PROTECTED
Yes.
> That is, it should be "START=0x3FF END=0x3FF" !?
>
> All four LKR files (200/202/204/206) have "0xFFF" at that line.
That should tell you its a bug right there. Even if the addresses were
somehow mapped strangely to the HEX file, they would still need to be
different between the 200/204 and 202/206. The 200/204 have the config word
at 1FFh.
As I said before, MPLAB has known bugs relating to config words and 10Fs. I
have used my own linker files, avoided the __CONFIG directive, and
everything worked fine.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________
Yes, I'm sorry... :-)
I just wasn't sure what was the problem...
> MPLAB has known bugs relating to config
> words and 10Fs. I have used my own linker files, avoided
> the __CONFIG directive, and everything worked fine.
OK.
I'll dowload a fresh copy of your environment and dig up
your LKR files. In this specific case, I'd like to stay in MPLAB,
so I'll check what has to be changed/added to the original
LKR files. Or maybe your LKR files are usable in MPLAB as-is !?
At last, let me express my sincere gratitude for your
invaluable help on this (and other) matter(s) !
> Olin wrote :
>
> > I have used my own linker files, avoided
> > the __CONFIG directive, and everything worked fine.
>
> OK.
> I'll dowload a fresh copy of your environment and dig up
> your LKR files.
Well, just did that, but could not find any LKR's
for th 10F's. I must be missing something, I though
they was included in the latest picdev kit :
"install_picdev.exe (1,336,832 bytes, 19 July 2004)".
I have also looked through the SW kits available from
the EasyProg page, but could not find them.
It's strange -- my experience with the PIC10F200 and MPLAB IDE v6.62 has
been completely different. I'm not really disagreeing with both of you
here -- I'm just reporting my findings -- maybe it might help you -- maybe
not.
I just completed a small PIC10F200 project and was able to use the CONFIG
directive with no problems -- even with the PIC10F200 linker script file
that has an "error" in it. In addition, even when I import the HEX file into
MPLAB IDE, the configuration bits get set properly -- so at least it appears
that MPLAB IDE "knows" how to parse the HEX file for the configuration word
if this is indeed an oversight on Microchip's part.
I used the quotes in the word 'error' above because, although I 100% agree
that the programming specification indicates that the configuration word
address is 0x1FF for the PIC10F200/PIC10F204 and 0x3FF for the
PIC10F202/PIC10F206, MPLINK "barks" at you if you try to correct the linker
script file by adjusting the configuration word address to what is called
out in the programming specification for the particular PIC10F part in
question:
For example, if I try to correct the error in the linker script by using
this for the PIC10F200:
----
MPLINK 3.80.03, Linker
Copyright (c) 2004 Microchip Technology Inc.
Error - section '.config' can not fit the absolute section. Section
'.config' start=0x00000fff, length=0x00000002
Errors : 1
BUILD FAILED: Sun Nov 28 22:02:12 2004
----
I just tried a quick experiment and I did find a pretty *strange* error
message when I try to do the following however:
CONFIG CODE
__CONFIG _MCLRE_OFF & _WDT_OFF & _CP_OFF
END
The error message I get is:
-----
MPLINK 3.80.03, Linker
Copyright (c) 2004 Microchip Technology Inc.
Assertion failed: found, file ../../mplink/src/MemTarg.cpp, line 710
This application has requested the Runtime to terminate it in an unusual
way.
Please contact the application's support team for more information.
BUILD FAILED: Sun Nov 28 22:13:01 2004
----
'CONFIG' is a logical section name defined in the PIC10F200 linker script
file. If I comment out the 'CONFIG CODE' part in the snippet above, the
error message goes away and all is fine. That's the only difference between
getting that error message or not getting it. I always just use the CONFIG
directive without encapsulating it within a CODE directive and an END
directive, but I wanted to try the experiment above. I'm not sure what is
considered better practice, but it would seem to me that the above snippet
would be better practice, but I cannot get it to work with MPASM/MPLINK. It
makes me wonder why Microchip includes a 'CONFIG' logical section name in
the linker script in the first place when the CONFIG directive works just
fine by itself...perhaps for the ability to get the address(es) of the
configuration word(s) for PICmicros that can programmatically read the
configuration word(s).
In any event, MPLAB IDE 7.0 is right around the corner and I'll be sure to
check out the PIC10F linker script files with that release. MPLAB IDE 7.0
was originally touted as being the release where component downloads is a
reality so that people would no longer need to download 30 something
megabytes.
> It's strange -- my experience with the PIC10F200 and MPLAB
> IDE v6.62 has been completely different.
I 'm using 6.60, not the 6.62.
I've browsed the readme's for 6.62, but could not find anything
pointing to this "problem", so it probably doesn't matter !?
B.t.w, have you actualy flashed any real device ?
And verifyed the config bits ?
> In addition, even when I import the HEX file into
> MPLAB IDE, the configuration bits get set properly -- so at
> least it appears that MPLAB IDE "knows" how to parse the
> HEX file for the configuration word if this is indeed an oversight
> on Microchip's part.
Not that unexpected, since MPLAB probably uses the same address
definition to both create and read the HEX file. Wrong or not.
> I used the quotes in the word 'error' above because, although
> I 100% agree that the programming specification indicates that
> the configuration word address is 0x1FF for the PIC10F200/
> PIC10F204 and 0x3FF for the PIC10F202/PIC10F206, MPLINK
> "barks" at you if you try to correct the linker script file...
That's why I'm still looking for Olin's files. According to an earlier
post from Olin, maybe they might be found on Philip's PC. And maybe
Philip, when he is back in real life (that is, on the PIClist :-) ), could
confirm this...
Another strange thing is that the adresses seems to be
OK in the .DEV files :
> Another strange thing is that the adresses seems to be
> OK in the .DEV files :
...
>
> This doesn't match up with the LKR files.
>
> Oh well, doesn't MC test their own tools ??
I think so! I have scanned the .DEV files (previously also .LKR files)
to extract information for my XWisp2 program and found several omissions
and contradictions. To my surprise MPLAB 6.62 is worse than 6.60!
{and I think: "typically windoze"}
Regards, Rob.
PS: I'll send you privately lists of programming parameters from
different MPLAB versions.
--
Rob Hamerling, Vianen, NL phone +31-347-322822
homepage: http://www.robh.nl/
____________________________________________
> > Oh well, doesn't MC test their own tools ??
>
> I think so! I have scanned the .DEV files (previously also
> .LKR files) to extract information for my XWisp2 program
> and found several omissions and contradictions. To my
> surprise MPLAB 6.62 is worse than 6.60!
> {and I think: "typically windoze"}
>
> Regards, Rob.
>
> PS: I'll send you privately lists of programming parameters
> from different MPLAB versions.
OK. Found the files in my mailbox. This is interesting :
(Should be read using a fixed font, I'd guess...)
Flash PIC properties from MPLAB device info in \mplab660\device\
Name DevID RevMask Prog Data ID-loc DevID-loc Config-loc ~Fixed-0 Fixed-1
(hex) (hex) (dec) (dec) (hex) (hex) (hex) (hex) (hex)
Jan-Erik Soderholm wrote:
> Well, just did that, but could not find any LKR's
> for th 10F's. I must be missing something, I though
> they was included in the latest picdev kit :
> "install_picdev.exe (1,336,832 bytes, 19 July 2004)".
>
> I have also looked through the SW kits available from
> the EasyProg page, but could not find them.
I guess I forgot to update the PIC development environment release. I won't
be able to fix that until late today since I'm at a customer site right now.
I tend to forget that there is a difference between what I'm running and
what is available on the net.
However, I created a PIC programmers software development release yesterday
which includes the latest PIC development environment. Go to http://www.embedinc.com/picprg/sw.htm and download the development software.
The linker files will be in the SOURCE/PIC directory.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________
Ken Pergola wrote:
> For example, if I try to correct the error in the linker script by using
> this for the PIC10F200:
>
> CODEPAGE NAME=.config START=0x1FF END=0x1FF PROTECTED
>
> I get the following error:
>
> ----
> MPLINK 3.80.03, Linker
> Copyright (c) 2004 Microchip Technology Inc.
> Error - section '.config' can not fit the absolute section. Section
> '.config' start=0x00000fff, length=0x00000002
> Errors : 1
This points out the error in the __CONFIG directive. Note that it tried to
put the config word at FFFh, which is definitely wrong. Apparently __CONFIG
specifies both the address and the section name, and you get an error if
this disagrees with the linker file.
The only part of what you reported that doesn't make sense is that it worked
in a real chip. I can see how MPLAB's bug could make it consistant with
itself. Did you use config bits other than 1? Have you verified that any
config bits set to 0 are actually in effect? Did the programmer wrap the
address somehow or otherwise correct MPLAB's error? What programmer did you
use?
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________
>The only part of what you reported that doesn't make
>sense is that it worked in a real chip.
I suspect that this is to do with the way the memory map wraps around when
the program counter goes over the top of the memory map. I suspect that the
upper bits of memory address are not actually there, and could be any mix of
ones and zeros, provided the lower 9 bits are 1FF. Hence by setting the
config to FFF they are also allowing for any future 10F series chips with
larger memory :))))
Alan B. Pearce wrote:
> I suspect that this is to do with the way the memory map wraps around
> when the program counter goes over the top of the memory map. I suspect
> that the upper bits of memory address are not actually there, and could
> be any mix of ones and zeros, provided the lower 9 bits are 1FF. Hence
> by setting the config to FFF they are also allowing for any future 10F
> series chips with larger memory :))))
It may be even simpler than that. The 10Fs wake up at the config address
when programming, then wrap to address 0 on the next increment. A
programmer just writes the config word immediately after a reset. The only
issue is that it might get confused about the data for the config word
depending on where it was expected in the HEX file and where it ended up.
My programmers look for the config data at a specific address. If any data
is found at an unexpected address it complains. This usually means you are
trying to program one PIC from a HEX file meant for another, and is why I
made it a hard error. I suppose other programmers might silently ignore the
config word from the incorrect address and default to FFFh since the value
wasn't specified. That's why I asked Ken if he verified that any 0 bits in
the config word were actually in effect.
Some programmers might mask addresses from the HEX file with the valid
address bits for the part being programmed, in which case the MPLAB bug
would go unnoticed. I guess being dumb is occasionally an advantage.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________
----- Original Message -----
From: "Ken Pergola"
> Hi Olin and Jan-Erik,
>
> It's strange -- my experience with the PIC10F200 and MPLAB IDE v6.62 has
> been completely different. I'm not really disagreeing with both of you
> here -- I'm just reporting my findings -- maybe it might help you -- maybe
> not.
>
> I just tried a quick experiment and I did find a pretty *strange* error
> message when I try to do the following however:
>
> CONFIG CODE
>
> __CONFIG _MCLRE_OFF & _WDT_OFF & _CP_OFF
> B.t.w, have you actualy flashed any real device ?
> And verifyed the config bits ?
Hi Jan-Erik,
Yes to both questions. I'm having no problems. I'm using MPLAB ICD 2 and
MPLAB IDE v6.62. If you have those tools, try it for yourself -- it should
work for you also.
> Apparently __CONFIG specifies both the address and
> the section name, and you get an error if
> this disagrees with the linker file.
Hi Olin,
By the way, how were you using the CONFIG directive?
1) Were you using it by itself like this example?:
__CONFIG _MCLRE_OFF & _WDT_OFF & _CP_OFF
2) Or were you using it with the CODE directive like this example?:
CONFIG CODE
__CONFIG _MCLRE_OFF & _WDT_OFF & _CP_OFF
I'm using MPLAB ICD 2 and MPLAB IDE v6.62. If you have the time, give it a
shot with those tools and I would imagine things would work out for you too
as long as you use HEX files generated from MPLAB IDE/MPASM/MPLINK. Like I
said, I'm going to pursue this further when MPLAB IDE 7.0 comes out before I
raise any questions in the Microchip Forums or technical support.
> The only part of what you reported that doesn't make sense is
> that it worked in a real chip.
Yes, if is definitely working with real hardware -- I'm using a PIC10F200.
> I can see how MPLAB's bug could make it consistent with itself.
Yes, I agree as well whether this is a bug or not. I'm personally not at a
point right now where I'd call this a Microchip error however. To shed more
light on the situation, I was hoping to see one of those "special notes" in
the PIC10F programming specification in which Microchip recommends placing
the configuration bits at a certain address. There isn't:
"When embedding configuration word information in the HEX file, it should
start at address XXXh."
> Did you use config bits other than 1?
Yes. WDT disabled ('0') and Master clear enable bit disabled ('0').
> Have you verified that any config bits set to 0 are actually in effect?
Yes. No watchdog timeout are occurring (as expected), and I'm using the GP3
as an input (the only choice) instead of as a /MCLR line.
> Did the programmer wrap the address somehow or otherwise correct MPLAB's
error?
> What programmer did you use?
I haven't looked into this since it is working for me -- I'm using MPLAB ICD
2 as the programmer with MPLAB IDE v6.62.
The Microchip standard configuration bit labels '_MCLRE_OFF' and '_MCLRE_ON'
let you choose whether you want to use the 'GP3/MCLR/VPP' pin as a standard
input pin (only choice -- output is not an option) or as a master clear
(/MCLR) pin, respectively.
> That's why I asked Ken if he verified that any
> 0 bits in the config word were actually in effect.
Hi Olin,
Yup, I responded to your question, but thread continuity is a little
frustrating with the long post delays. You should see my answer either
before or after this message hits...or even before I write it :) (space time
continuum)
Ken Pergola wrote:
> By the way, how were you using the CONFIG directive?
>
> 1) Were you using it by itself like this example?:
>
> __CONFIG _MCLRE_OFF & _WDT_OFF & _CP_OFF
>
> 2) Or were you using it with the CODE directive like this example?:
>
> CONFIG CODE
>
> __CONFIG _MCLRE_OFF & _WDT_OFF & _CP_OFF
#1. You can look in the HEX file and see that it puts the config data at
the wrong address.
> I'm using MPLAB ICD 2 and MPLAB IDE v6.62. If you have the time, give
> it a shot with those tools and I would imagine things would work out
> for you too as long as you use HEX files generated from MPLAB
> IDE/MPASM/MPLINK.
I never tried it with the ICD 2. I've been using my own programmers from a
script that does some other things too. You can't do that with the ICD2.
In any case, I don't have a problem anymore. It's working fine for me, I
just can't use the __CONFIG directive, which is already long gone from my
10F code.
> Like I said, I'm going to pursue this further when
> MPLAB IDE 7.0 comes out before I raise any questions in the Microchip
> Forums or technical support.
I reported this to Microchip quite a while ago and they acknowledged it is a
bug. It will likely be fixed in the next version.
> I'm personally not at a point right now where I'd call this a
> Microchip error however.
I did and they agreed.
> "When embedding configuration word information in the HEX file, it
> should start at address XXXh."
None of the PICs have such a clause because the configuration word is in the
normal program memory address space. There is therefore no need to map it
so some special address. This is different for data EEPROM because that's
in a separate address space and can't be put in the HEX file at its native
location because it would overlap with program memory.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________
d1o407.telia.com>
