gnupic: Re: [gnupic] Cannot get 18f252 to blink-success!!
Subject:
Re: [gnupic] Cannot get 18f252 to blink-success!!
From:
David Froseth ####@####.####
Date:
25 Oct 2006 06:01:25 +0100
Message-Id: <453EEF5A.6010305@umich.edu>
Thanks guys for the replies,
I got it working. What I did is I erased the program memory in the
18f252 before I tried programming it again. (?)
When I first tried to program and read it again, I got the same exact
program memory read:
$ picp /dev/tty.KeySerial1 18f252 -rp
:020000040000FA
:10000000040E0060000E926E9200000E000E0000C2
:10001000010C0000000000000000000000000000D3
:10002000000000000000000E000000000020006042
:100030000000000000000000020E016C0020046EB1
:100040000000000E004000000000012E250E0020E0
:10005000002023EF00F0020026EF00F0082E24EF2E
:1000600000F0052E22EF00F0120037EF00F00150F3
:10007000806E1200FFFFFFFFFFFFFFFFFFFFFFFF8C
:10070000F9263F0C060C5B0C4F0C660C6D0C7D0C37
:10071000070C7F0C6F0C400CFFFFFFFFFFFFFFFF7C
:00000001FF
I cannot get gpsim to work on my mac, and gpdasm is not available for
the mac, I don't think. The good news is that I am currently building a
computer to run linux, and I will not be isolated any more from all of
the wonderful software and hardware that is available for pic programming.
Scott, I agree that the de-assembled code looks very strange. I wonder
what happened? I successfully programmed 16f870 and 16f84a chips with
the Picstart+. I wonder if the new code de-assembles into the right
assembly code this time.
Knowing that the code was coming out strange (thanks Scott), I decided
to try and erase the chip before reprogramming it. When I programmed it
and read it, I got:
$ picp /dev/tty.KeySerial1 18f252 -rp
:020000040000FA
:100000000CEF00F0FFFFFFFFFFFFFFFFFFFFFFFF11
:10001000FFFFFFFFFFFFFFFF060EC16EFE0E926E99
:10002000FF0E936E000E946E010E801A1AEC00F013
:1000300014EF00F0FF0E206EFF0E216E212E1EEF3A
:1000400000F0202E1CEF00F01200FFFFFFFFFFFF6B
:00000001FF
This is obviously very different. I plugged it into the circuit and
got the blink! Is it standard procedure to erase the chip before
writing to it? I thought that reprogramming it automatically did that.
I would really like to understand what I am seeing when I look at these
hex files and program reads. The new info coming out of the chip is
still different than the .hex file. I imagine that both look different
than the visual program memory tables that you see in gui simulation and
programming software.
Thanks, Jeffrey for the Hex format specs pdf. The info is way over my
head, though. "The Quintissential PIC Microcontroller", by Katzen is
very good at explaining what the program number codes mean. What I did
get from the pdf is that the pic's number codes then get number coded -
very confusing.
Dave
Scott Dattalo wrote:
> ####@####.#### wrote:
>
>> David,
>>
>> I beleive that the 18f252 does split RAM and function registers at
>> 0x80. Have you
>> tried gpsim? As an aside, the 18f has "bra" instructions that assemble
>> to single word
>> opcodes that could be used in place of the longer/slower "goto"'s.
>
>
> George,
>
> These were my thoughts too. For gpsim both the .cod (obtained from
> assembling the .asm file) and the .hex simulate correctly. However, the
> second .hex file is corrupt. gpdasm gives:
>
> $ gpdasm -i -p 18f452 t.hex
> hex file name: t.hex
> hex file format: inhx32
> number of bytes: 160
>
> 000000: 0e04 movlw 0x4
> 000002: 6000 cpfslt 0, 0
> 000004: 0e00 movlw 0
> 000006: 6e92 movwf 0x92, 0
> 000008: 0092 dw 0x92 ;unknown opcode
> 00000a: 0e00 movlw 0
> 00000c: 0e00 movlw 0
> 00000e: 0000 nop
> 000010: 0c01 retlw 0x1
> 000012: 0000 nop
>
> It appears that either the device is programmed incorrectly or the
> programmer is incapable of reading the program memory.
>
> David,
>
> Has the device ever programmed correctly before? And, do you know if
> your programmer even works?
>
> Scott
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
>
>
