headers
David | 1 Jan 01:59
Picon

[PIC] relocation of code using HiTech C compiler

I am trying to get a bootloader running with the PIC18LF1320 micro and 
find the program is writing over itself.

The bootloader calculates the memory top and erases from where 
bootloader ends and the end of memory.
The problem is that instead of the bootloader being placed in the bottom 
0x300 bytes the compiler is placing most of the code up at 1B62. This 
means the bootloader writes over itself when it runs.

Does anyone know how I can make the Hi-Tech C compiler put the 
bootloader code in the block from 0000 to 0300 ?

Thanks

Regards

David
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 5 comments |
headers
Brent Brown | 1 Jan 02:50
Picon
Gravatar

Re: [PIC] relocation of code using HiTech C compiler

David wrote:
> I am trying to get a bootloader running with the PIC18LF1320 micro and
> find the program is writing over itself.
> 
> The bootloader calculates the memory top and erases from where 
> bootloader ends and the end of memory.
> The problem is that instead of the bootloader being placed in the
> bottom 0x300 bytes the compiler is placing most of the code up at
> 1B62. This means the bootloader writes over itself when it runs.
> 
> Does anyone know how I can make the Hi-Tech C compiler put the 
> bootloader code in the block from 0000 to 0300 ?

Just for an example that might give you some clues... to get the TinyBootloader to 
work in a recent PIC project I had to tell the compiler to NOT put application code 
where the Bootloader resides. In my case I added the following in MPLAB under 
Project/Build options/Project/PICC Linker - use alternate settings: 

 -RESROM1F9C-1FFF

Typically your Bootloader code will be compiled/assebled sepeartely from your 
application code and should have directives to be located at a specific address. As 
shown in the example above, your application code might reasonably be expected 
to reside anywhere else in your chip except where the Bootloader resides.

Hope that helps some!

--

-- 
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
(Continue reading)

Permalink | Reply | 3 comments |
headers
John Temples | 1 Jan 03:00

Re: [PIC] relocation of code using HiTech C compiler

On Mon, 1 Jan 2007, David wrote:

> Does anyone know how I can make the Hi-Tech C compiler put the
> bootloader code in the block from 0000 to 0300 ?

Check the --rom command line switch in the manual.  This lets you
override the compiler's idea of what memory ranges are available to it
for placing code.

--
John W. Temples, III
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 0 comments |
headers
Rich | 1 Jan 04:04
Picon

Re: [EE] Gargoyle?

I went to gargoyle.com and found a variety of things including, gargoyles, 
sun glasses, etc.  So I reasoned that gargoyle must be a pun on google.

----- Original Message ----- 
From: "Denny Esterline" <firmware <at> tds.net>
To: "Microcontroller discussion list - Public." <piclist <at> mit.edu>
Sent: Sunday, December 31, 2006 6:27 PM
Subject: Re: [EE] Gargoyle?

>> I've heard a couple of references to Gargoyle lately, googling Gargoyle 
>> and
>> Electronics doesn't come up with anything too spectacular... can anyone
>> enlighten me?
>>
>> Blair
>>
> As others have pointed out gargoyle is used as a euphemism for google, but 
> it did come about for more reasons than just "techno-speak". Back a few 
> months ago Google was involved in some legal fuss about people using the 
> term google as a generic verb meaning "to search the web" instead of their 
> preferred Google, a proper (and trademarked) noun.
>
> -Denny
>
>
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>
(Continue reading)

Permalink | Reply | 16 comments |
headers
Steve Ravet | 1 Jan 04:47
Favicon

RE: [EE] LANC, SIRCS, S-LINK or USB? .. was: Remote


> >
> > Sounds promising - it's flash programmable and that's a big 
> plus in my 
> > book. Is the PICDEM USB board totally essential for 
> prototyping, would you say?

I missed the beginning of the thread.  If you're wanting to prototype a
USB slave the FSUSB is a handy thing to have on hand, especially if,
like me, you're new to PICs, to designing PCBs, and to USB.  The PIC
pins are brought to headers so you could prototype some peripheral logic
with it prior to designing a PCB if you want.  If nothing else the FSUSB
schematic is handy as a reference for the USB  connections, you can
download it without getting the board.

--steve

--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 0 comments |
headers
Carey Fisher | 1 Jan 04:55

Re: [EE] Fractal chip antennas


> A 50 ohm resistor has great return loss, but I've not made too many DX
> contacts on them.
>   
Remember using light bulbs for dummy loads?  Used to make plenty of 
contacts on them!
K8VZ
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 1 comment |
headers
David | 1 Jan 06:11
Picon

Re: [PIC] relocation of code using HiTech C compiler

Hi,

The problem IS with the bootloader code. The application is loaded by 
the bootloader later and is offset by 0x300.

The Bootloader when compiled uses just under 0x300 bytes (a bit larger 
than original Hi-Tech bootloader due to encryption decoding and 
bit-bashed serial.

But, when I compile the bootloader it puts a small amount of code at 
0000 to about 0026 than puts the rest of the bootloader code just below 
top of memory.

I have used the same base code for the PIC18F6720 and PIC18F2520 and the 
compiler does place all the bootloader code between 0000-0300 in these 
programs. In fact this version was created from the working PIC18F2520 
bootloader with minor changes to set up the OSCCON and Port direction 
registers only

I tried --ROM=0000-0300 but this did not fix the problem. I cannot 
understand what determines that some of the code gets pushed into upper 
memory and why it all cannot simply compile linearly into memory from 
0000-02ff as the other versions do ??

Would anyone be prepared to take a look at it if I zipped the project up 
and emailed it to you to see if I have done something silly ?

I am using Hi-Tech compiler V9.5 PL3 and MPLAB V7.51. Target device is 
PIC18LF1320.
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Temples | 1 Jan 06:48

Re: [PIC] relocation of code using HiTech C compiler

On Mon, 1 Jan 2007, David wrote:

> I tried --ROM=0000-0300 but this did not fix the problem.

Tried it how?  You realize that's a linker option, not a compiler
option, right?

--
John W. Temples, III
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
Permalink | Reply | 1 comment |
headers
David | 1 Jan 06:55
Picon

Re: [PIC] relocation of code using HiTech C compiler

John,

Thank you for pointing that out to me. I did have the command line 
option in the wrong place (under compiler tab instead of linker).

That does in fact now place all the code in the bottom of memory as desired.

Any idea why the compiler would do otherwise by default ?

Regards

David

John Temples wrote:
> On Mon, 1 Jan 2007, David wrote:
>
>   
>> I tried --ROM=0000-0300 but this did not fix the problem.
>>     
>
> Tried it how?  You realize that's a linker option, not a compiler
> option, right?
>
> --
> John W. Temples, III
>   
--

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert Rolf | 1 Jan 09:45
Picon
Picon
Favicon

Re: [EE]: bluetooth and cordless phone interference. Lip sync

Herbert Graf wrote:
> On Sun, 2006-12-31 at 11:10 -0200, Gerhard Fiedler wrote:
> 
>>This probably makes in not suited for TV, right? Sometimes there is a
>>channel with audio and video slightly out of sync, and it seems it's less
>>than 1/4 second that can create this out-of-sync feeling.
> 
> 
> Absolutely, 250ms may not sound like much, but to me that much delay in
> the audio would intolerable. TTYL

And extremely obvious.

The typical lip syncing error you see is due to the 'frame sychronizers' that
stations use to sync their incoming live feeds with station sync. They SHOULD
be sending the audio through the synchronizer so that it can insert a matching delay,
but often the video then goes separately through a couple of digital switchers and ends up
being delayed by a frame or two or three (33ms delay *IS* visible to practiced eye).
This leads to that out-of-sync feeling.
Newer stations have the synchronizers built right into the switcher, so the audio never
gets processed in the first place.

It is also possible that there is a clock rate error in the playback of an MPG recorded
program, where the audio and video clocks on playback are slightly off, so that by the
end of the program, there is a noticeable error between the two streams.
You often see this with Winblows media files.

My wife just received a bluetooth earpiece for Christmas, and when testing it in
the house the 1/4 second delay was MOST annoying, particularly since I was also hearing
my OWN voice back from the earpiece (Motorola H350 with Samsung A920).
(Continue reading)

Permalink | Reply | 0 comments |

Gmane