I have just embarked on using PICs having been a die-hard Analog guy for years (more than I care to mention !).
For my sins I have got hold of Myke Predko's huge tome on the subject, partly because of the inclusion of the El Cheapo programmer (programer), and have slowly been battling my my through it.
Having built the El Cheapo (and then again with the latest mods), and updated the software to 0.77, it flies through all the debug routines with ease. The problem is that when I program the 16F84 with the Ledon.hex which simulated great in MPLAB, it fails miserably in the breadboard. It does nothing in fact but show clock activity.
The same hex code used with a borrowed programmer works great when plugged in to the circuit. This anonymous machine seems to read the PIC programmed on the El Cheapo as empty program space.
What next ? Any help here would be greatfully received.
On Sat, May 11, 2002 at 08:50:35PM +0100, Ken Evans wrote:
>[El cheapo problems described]
I can't help you there. But in an never ending quest to fill the information
gap, I'd like to suggest that after you get started that you may want to
upgrade your 16F84's. Check out this page:
The Warp showed that all that had been written was the fuse bits (I had been
able to verify that before getting the Warp by changing to/from the internal
osc. in the 628 and scoping the clock pins). The rest of the program memory,
though, was blank.
I have not had time to get to the bottom of the problem (and have no need
to, now I have a Warp). If you get it working, I'd like to hear about it.
"Gary Russell" <gary-russellKILLspamPSUALUM.COM> said:
> I had the same problem...
>
>
www.piclist.com/techref/postbot.asp?by=time&id=piclist\2002\03\16\192
> 133a&tgt=post
>
>
> I never got it to work...bought a Warp13a (http://www.phanderson.com/)
>
> The Warp showed that all that had been written was the fuse bits (I had
been
> able to verify that before getting the Warp by changing to/from the
internal
> osc. in the 628 and scoping the clock pins). The rest of the program
memory,
> though, was blank.
>
> I have not had time to get to the bottom of the problem (and have no need
> to, now I have a Warp). If you get it working, I'd like to hear about it.
Insufficient 13V Vpp?
Dodgy software?
I've actually got two selfbuilt programmers - a JDM "PIC Programmer 2" and a
Maplin "PIC16C84 Programmer" (a modified David Tait programmer with 7407
buffers). Both of them work fine. What I'd suggest is building a Tait style
programmer ("Classic" variant, parallel port, needs a 12V unregulated or 15V
regulated PSU). They tend to work first time and can be made quite small
with surface mount components. The JDM is also a good programmer and is ICSP
capable (so is the Tait programmer, if you add the ICSP cable). Just one
warning - you MUST use a tantalum capacitor for the 22uF cap in the JDM
programmer circuit. A normal alu electrolytic will NOT work (I found that to
my cost).
If you really want to use the Elcheapo, check the Vpp (13V) and Vcc (5V)
lines, then check that there's activity on the data and clock lines. Check
it against the programming specifications. I'm willing to wager that one of
these is the cause. You might want to try older software, too - sometimes a
bug can creep in and cripple the program, whilst an earlier version works
fine...
Sorry I've been quiet - I got nailed yet again with a virus on my home mail
server (I think I'm going to go from Win2K to Linux *very* shortly). This
is the forth time this year - sigh.
You may get this email from me twice because I'm putting it on both the
PICList as well as sending it to you directly.
In any case, could you please drop me a line with the following information:
1. What were the voltage levels of the PCB when you went through the test
steps?
2. What operating system are you running?
3. Did you "Verify" the programming from the programmer? What about the
borrowed programmer?
1/ Voltage levels. I don't remember the precise levels, although they were
comfortably within your limits. I think the MCLR level was about 13.1V and
Vdd 5.1V.
I can check these again if necessary ??
2/ Windows 98SE
3/ The El Cheapo Verified OK
The other programmer was a homebult serial port device, of an anonymous web
design, running with Pix software. It confirmed the first byte of the El
Cheapo programmed (and verified) PIC was zero and the rest were blank
(3FFF). It successfully programmed the PIC which ran in the breadboard, with
the same Hex file.
The process was repeated several times to confirm everything.
> Myke
>
> thanks for response.
>
> 1/ Voltage levels. I don't remember the precise levels, although they were
> comfortably within your limits. I think the MCLR level was about 13.1V and
> Vdd 5.1V.
>
> I can check these again if necessary ??
>
> 2/ Windows 98SE
>
> 3/ The El Cheapo Verified OK
>
> The other programmer was a homebult serial port device, of an anonymous web
> design, running with Pix software. It confirmed the first byte of the El
> Cheapo programmed (and verified) PIC was zero and the rest were blank
> (3FFF). It successfully programmed the PIC which ran in the breadboard, with
> the same Hex file.
>
> The process was repeated several times to confirm everything.
You may have run into a problem in the El Cheapo software (version 0.77)
that I discovered recently. It only activates if you use recent versions
of MPLAB (presumably the new version of the command line MPASM has the
same problem).
For some reason, this new version sometimes starts the hex file with an
extended linear address record (32 bit address record), otherwise known
as record type 4, even though there is no good reason to include such a
record in a hex file for a processor with far less than 16 bits of
address space. This record confuses the El Cheapo software; the result
is that the PIC doesn't get programmed correctly.
The workaround is to edit the .HEX file, and delete the first line. Then
run the El Cheapo software and program the part.
Argghhh... Mark is right with the latest version of MPLAB (5.6), the
default hex file output is INHX32 and NOT INHX8M which the El Cheapo
expects.
If you are using MPLAB 5.6, go into "Edit Project" and check to see what is
the hex file format. It should be INHX8M for Version 0.77. Version 0.81
will be available in the next week or so and with it I will fix this problem
(as well as PIC16F7x support amongst other enhancements).
When I was asking about voltage levels, I was really most concerned with the
Data line voltage level. With some PCs a very small (330 Ohm) resistor is
required for R2.
So Ken, let me know if you have MPLAB 5.6 and if you are having any trouble
changing the project parameters.
Interesting - they're getting ready for the DSPic...?
"Linear program memory addressing up to 4M instruction words"
With 24bit wide instructions that's 12MB. Does the INHX8M standard
address that much space? If not I can see MPLAB defaulting to the
larger format for all the PICs only to make things more consistant.
Commercial programmers are likely set up to accept a wide variety of
formats so they won't be affected, only community and hobby made
programmers might be affected.
I wonder if this change in defaults is mentioned in any release notes...
>
>
> You may have run into a problem in the El Cheapo software (version 0.77)
> that I discovered recently. It only activates if you use recent versions
> of MPLAB (presumably the new version of the command line MPASM has the
> same problem).
>
> For some reason, this new version sometimes starts the hex file with an
> extended linear address record (32 bit address record), otherwise known
> as record type 4, even though there is no good reason to include such a
> record in a hex file for a processor with far less than 16 bits of
> address space. This record confuses the El Cheapo software; the result
> is that the PIC doesn't get programmed correctly.
>
> The workaround is to edit the .HEX file, and delete the first line. Then
> run the El Cheapo software and program the part.
>
> --
> http://www.piclist.com hint: The PICList is archived three different
> ways. See http://www.piclist.com/#archives for details.
>
>
>
>
>
mitvma.mit.edu
