I missed the beginning of this thread.  What C compiler are you using?  The
latest versions of Hi-Tech PICC-18 already handles the 0x4000 boundary problem
for you.  If you're using PICC-18, you don't need special code.

-Mike

-----Original Message-----
From: Jai Dhar [mailto:jai.dhar@STERNERAUTOMATION.COM]
Sent: Friday, September 12, 2003 9:36 AM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: More 18F458 Quirks


You said it exactly, it's a problem with C that makes it harder. Take my
example that I gave before... if I am calling foo() from main(), in the
function definition of foo, I can't simple go:

void foo()
{
_asm
 data 0xffff
_endasm

..the rest

}

since the line void foo() itself creates a whole prologue of stack/frame
pointer modifications. That's why I need to call an access function which is
written in assembly, so I can insert the line 'data 0xffff' as the first
instruction. After re-reading the errata, it doesn't mention that I have to
put the 0xffff in the same region in memory, so I guess that answers
question. Here's something else to make matters more complicated:

I'm starting from scratch, ie, working with the version of code that works,
but is unsplit. I then verified that the problem wasn't there, and it
wasn't.. next step, I simply split the code, but didn't use any access
functions. Just to put it in the right place... NOW, for my lowinterrupt
vector, it jumps to an access fn called LowInt_access, which inserts the
0xffff. If I let the linker automatically allocate where LowInt_access
resides, I didn't have a problem (It placed it around 0x6000), but as soon
as I restricted it to 0x3f00, the problem started again. I don't think this
sources the problem, but I think it shows how one little modification can
make things go haywire.

I had no idea PIC's were this buggy???

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Jan-Erik Soderholm XA
(TN/PAC)
Sent: September 12, 2003 12:24 PM
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC]: More 18F458 Quirks


I have re-read the errata sheet, and remember seeing it before.
It doesn't say you need a stub routine between your main and sub.

You have to insert a FFFFh at the *target* of any jump over the
4000h "boarder line" :

  1. Insert a data word of value FFFFh as the first
  instruction in the destination of a CALL or GOTO.

  2. Insert a data word of value FFFFh immediately
  following any RETURN, RETLW, or RETFIE instruction.

So, whenever the PIC jumps over the 4000h boarder (from
executing a CALL or GOTO), it has to see a FFFFh instruction
as the first one.

Note also that the RETURN (if it "returns" over the 4000h
boarder) needs FFFFh directly *after* the RETURN instruction,
not at the *target* of the RETURN ! Could easily be fixed with
a "458_RETURN" macro that inserts both the RETURN and the FFFFh.

Or is it be something with "C" that makes this harder
to implement ?

Jan-Erik.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body