Subject:
Re: New Command to picp
From:
Declan Moriarty ####@####.####
Date:
6 Dec 2002 12:43:56 -0000
Message-Id: <02120611340300.00605@genius.chateau.dec>
On Friday 06 December 2002 05:12, you wrote:
> On Fri, 6 Dec 2002 1:30 pm, Andrew Pines wrote:
> > I added the flash erase command that Antonio worked out but I don't have
> > any
>
> flash parts to test it.
>
> > If any brave soul would like to try it out, I made a test version which
> > is
>
> available here:
> > ftp://ftp.cosmodog.com/outgoing/picp-0.5x.tgz
Having bellyached so much over this, I felt honour bound and tried it. I
reached for a 16f877 and skipping repetitive trivia in command lines, here's
what I got. My op system is a rather incomplete LFS system with a bare kde
install running e-mail temporarily. I start lfs, dial up, chroot to mandrake,
start X and get e-mail there. This may account for some errors.
the line was picp /dev/ttyS1 16f877, followed by
-b Complained about Picstart 2.30 Firmware. HMMMPH!. A change of 17C44
followed. "here's one I made earlier", etc. (3.0040)
-b Program & configuration not blank. Standard enough response
-ef no error - returned a prompt within 5 seconds
-b error - 'failed to send blank check command'
I got this for any -b command I sent investigating the pic, but
-wc 0x3fff was swallowed, and then
-rc gave me 0x3fff
-rp > down.hex gave me output.
gpdasm down.hex |less showed it was indeed blank
-wp (revise3.hex) segfaulted. But a repeat of the procedure above showed the
program had been loaded to the last byte.
-b now returned program not blank, configuration blank. It appears the error
provoked by the -ef command relates to the end of the program area
-rc returned 0x3fff = blank
This places the segfault at the end of the programming/ writing the config
word. The assembler has the __CONFIG directives in it, so with picp-0.4f and
2.3 picstart firmware, -wp would also write the configuration word as 0x3f38.
-rp down.hex & gpdasm down.hex |less showed that the last byte of the program
was successfully loaded
Previous versions of picp (0.4f, 0.5b, 0.5c) behaved as follows
0.4f barfed on the picstart frimware
0.5b -b returned correct info
-wp segfaulted on exactly the same spot whereas previously 0.4f would write
the config bits . See below.
0.5c I downloaded that. It wouldn't make
"No such file or directory" True - mandrake doesn't have make installed BAH!
lfs terminal:
The make barfed on the first line
cc1plus: Invalid option '-fmessage-length=0'
diff showed that as the only difference between 0.5c and 0.5x. Makefile. That
is what vi is there for :-D. One make later, it returned exactly as 0.5b
Now with NO PIC AT ALL, -wp still returns the segfault, along with a 'failed
to verify program space' error from the 0.5 versions, and my 17c44 that was
the subject of an earlier query to Andrew. It barfed on the programming, but
seemed OK. Care to revise your opinion on it, Andrew?? :-D. Specifically, if
I write one now(0.5c or 0.5x & psf30040.hex loaded as is), will it do any
better??
This is my first experience with psf30040.hex and the new firmware. Maybe the
17c44 I programmed up wasn't so great after all. But I don't see where I went
wrong. If this is fingered, take note that the 2.3 picstart firmware is not
compatible with your updating process.
I have kernel 2.4.18, glibc-2.2.5, and gcc-2.95-3 with some other patch
applied (=2.95-4?) if any of that matters.
In summary, it works, but throws errors. An insight is this:
-ef failed to send blank check command
failed to erase flash device
-rp file might throw an error, but apparently fixes whatever error is there.
I got the interesting sequence that -ef threw errors; the first time I ran
-rp after that it threw errors, but subsequently running the same command
caused no errors, when one would expect a repeat of the error.
If you want any other checks done here, yell.
--
Regards,
Declan Moriarty
