I spent a lot of time reading PIC documents today. I am full of disjointed
facts, no cross referencing, and a subtle lack of coherency.
The On Chip Debugger Specification document, 51249a.pdf, mentions the
In-Circuit Serial Programming (ICSP) Guide (DS30277). At the Microchip
site this morning, the search engine was down and I could not find
it. Does anyone have a good URL to a copy of DS30277?
I read in 39025.pdf, EEPROM Memory Programming Specification, that the
EEPROM memory is at word address 2100-21FF, and that this can be put into
the HEX files. With some search, I may have produced an .asm file that
makes this happen. Can anyone give a URL for a .hex file which has EEPROM
data in it, or confirm that their programmer will write EEPROM from my .hex
file, URL below?
There is occasionally a reference to "Test Memory". This is mentioned in
paragraph 2.4.7.2 of 39025.pdf. The file "MPLAB IDE\Device\pic16f874.dev"
mentions 2000-20FF as the address for "test memory"
I happen to have a 16F874 part in my project right now. The same part Olin
questioned the need of last summer. This is a limited memory part. The On
Chip Debugger documentation says, in part, that the OCD uses the last 100H
words of memory, but other documents say that it uses the addresses at
1F00-1FFF. Guess what? I programmed code at 1F00-1FFF, read back code
from 0000-1FFF, and I get that code back, without aliasing. I interpret
this to mean that the 16F874 does have 100H words at 1F00-1FFF.
Does anyone know a way to write RAM locations with the In Circuit Serial
Programmer?
With a homebrew OCD, after setting the ICKBUG and BIGBUG registers, BKBUG
in the config word, and have the goto vector at word address 2004 set
correctly, how can I possibly handle PCLATH?
Has anyone made a homebrew OCD to go with their in circuit programmer?
The files in this directory are exploratory. They may not ever make
sense. They may change.
Other files in this directory may be better suited to this discussion.
> The On Chip Debugger Specification document, 51249a.pdf, mentions the
> In-Circuit Serial Programming (ICSP) Guide (DS30277). At the
> Microchip
> site this morning, the search engine was down and I could not find
> it. Does anyone have a good URL to a copy of DS30277?
IIRC these documented used to be on the page fro the chip, but they seem
to have vanished. email me privately for a copy. I assume you want the
one for the 16F874?
> I read in 39025.pdf, EEPROM Memory Programming Specification, that the
> EEPROM memory is at word address 2100-21FF, and that this can
> be put into the HEX files.
This is convention, ot has little to do with the hardware.
> Does anyone know a way to write RAM locations with the In
> Circuit Serial Programmer?
Jan-Erik Soderholm says:
>Hi. Besides of the fact that this isn't possible (as Wouter also pointed
>out), why would one need to do this at all ?
With good enough software, the In Circuit Serial Programmer Host becomes
the On Chip Debugger Host. There only has to be a little more intelligence
on, for example, dropping PGM_Clock, and coordinating data coming from the
ICSP socket.
One of the first tasks is to write the two RAM locations, ICKBUG and
BIGBUG. If it were possible to do this with simple bit banging on the
PGM_Clock and PGM_Data lines, I would do it that way.
At this point, I have recovered an .asm file that will re-create the .hex
file mentioned earlier. Now, I guess I'll have to put the comments into
it, and see how it does things.
> last 100H words of memory, but other documents say that it uses the
> addresses at 1F00-1FFF. Guess what? I programmed code at 1F00-1FFF,
> read back code from 0000-1FFF, and I get that code back, without
> aliasing. I interpret this to mean that the 16F874 does have 100H words
> at 1F00-1FFF.
Now that is interesting. So program memory is not sacrificed when using
ICD on the smaller parts.
I'll stay tuned to this thread.
Thanks,
Bob
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
part 1 2431 bytes content-type:text/plain; (decoded 7bit)
I think Aubrey may have been confused by the doubling of addresses in the
HEX file.
The DE874.HEX file for use with the ICD that I have loads at 0xF00 through
0xFFF when imported into MPLAB.
I'm not sure how she got non-aliased values from 1F00-1FFF, though.
I am just about completely finished disassembling the entire DE874.HEX file.
I have attached my work so far. The code uses a few neat tricks, but there
are a couple basic things that could be greatly improved.
many times to perform a pseudo-CALL to the IoRoutine without using a stack
level.
The IoRoutine returns by:
movf xIoRetAddr,W
addlw 3
movwf PCL
This is sneaky, but could be greatly improved by:
movf PCL,W
goto IoRoutine
Then, at the entry point of the I/O routine:
movwf xIoRetAddr
And the exit code could be changed to:
incf xIoRetAddr,W
movwf PCL
This saves 2 words for each use of the pseudo-CALL. Given that there are 20
such pseudo-calls it would save 40 words of memory. This is 40/256 or 15.6%
of the total memory used by the debug code.
Bob Ammerman
RAm Systems
{Original Message removed} part 2 9489 bytes content-type:application/octet-stream; (decode)
Bob Blick says:
>Now that is interesting. So program memory is not sacrificed when using
>ICD on the smaller parts.
>I'll stay tuned to this thread.
Another question that I thought of is whether this is "memory" or a
"register," i.e. does it persist after power down. I haven't tested.
At a cost on only 26 or so hours, I have edited the .hex file so that it is
more readable by people. For example, I replaced the phrase "0800" with
the phrase " return," and so forth.
I am certain that I understand how it works, have control over it, and can
use it to do other things.
I decided to email a permission to publish request letter to .....tech.supportKILLspam@spam@microchip.com, just to be clean, and I haven't uploaded this
file. When my ISP is back up :-( I will reconcile my web site and
Microchip's response.
Has anyone pursued "permission" from Microchip, and are there contacts you
might mail me privately?
It turns out that the code is almost exclusively dedicated to read / write
single bytes which are accessible via FSR and INDF. No program or EEPROM
memory is touched. This, of course, answers my earlier question about
modifying data RAM. The dispatch table has 26 entries, but most of them
jump to "Send_NAK"
The most curious thing that I found was that they use 16H bytes of code to
save an image of the STATUS register. One thing they do is to copy STATUS
(arbitrary bank) to STATUS (bank 3). Although this seems odd, the on chip
debugger document does say that the high and low PORTB registers act
differently. Seen against the tight code space, this effort seems significant.
They also have a macro to "call" a routine and "return" without affecting
the hardware stack, and only consuming 1 RAM location (all in same code page).
mitvma.mit.edu
