Jump to content
Sign in to follow this  
amohr

C2C + bootloader

Recommended Posts

so I've scoured the forums and google and haven't found any info.  How can I make the following bootloader(http://www.microchipc.com/PIC16bootload) work in C2C?

 

From what it states the top 256 bytes need to be reserved, however I don't see any way in C2C to set the ORG address, nor to reserve the top 256 bytes.  

In CC5X 3.1 it states this would be done the following way for a PIC16F877:

#pragma chip PIC16F873, core 14, code 0x1F00, ram 32 : 0xFF /0 /3 //set top address to protect bootloader code

 

As far as the cdata changes it tells to make for CC5X I assume these go into #pragma RESERVE_ADDR.  However how about the resetVector?

 

Thanks!

 

- Alex

Share this post


Link to post
Share on other sites
Guest Pavel
From what it states the top 256 bytes need to be reserved, however I don't see any way in C2C to set the ORG address, nor to reserve the top 256 bytes. 

Is there any reason this code can't be placed at the end of the code memory with a goto placed on the address 0 that jumps to the bootloader code?

 

Regards,

Pavel

 

PS:I probably need to add a new #pragma (or something similar) that will tell how big is the target code space so that some code can be placed at the end of available code space. Will this be helpful?

Share this post


Link to post
Share on other sites

I wrote a bootloader in CC5X, and place the code

in high memory block, and then put a goto to the

reset vector, it's work very well.

The bootloader is testing some input to define

if must work like bootloader or call the user program.

 

Bye

Daniel

Share this post


Link to post
Share on other sites
Guest Pavel

Let me describe my view on a bootloader vs C2C issue.

 

From technical point of view it doesn't matter where the bootloader code resides. When a chip is powered up a jump on address zero (along with page set) directs execution flow to the bootloader code that checks if bootloader should download some new code or just make a jump to the main application code.

 

Using this strategy a C2C bootloader code must use #pragmas to reserve code space at the address 0 (and maybe 1 and 2 for page set instructions) and place bootloader functions at the end of code space. Though currently it's not possible to have a 'main' function placed at arbitrary address or to compile code without a 'main' function these issues can be easilly overcome. There may be a dummy main that will just call a bootloader entry function and which will not be used in final assembler since the goto of the address 0 will direct execution to the bootloader entry. And to place the bootloader code at the end of code space a function with fixed address should be used (look here).

 

The only missing part for a C2C bootloader application is an ability to make target independent code be placed at the end of code space. But since bootloaders usually work with only one or a limited number of targets and because a fixed function address can be used this feature is a nice to have but not mandatory. (I plan to add it later)

 

Though writing a bootloader is a challenge I don't see any technical issues that can prevent creating bootloader code with C2C.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Pavel,

 

I guess that you think is right, but I need few days for test it.

 

Regards

Daniel

Share this post


Link to post
Share on other sites
Guest here's the way I see it

I'm trying to reuse code so that I don't need to write my own bootloader.  I don't want to have to re-invent the wheel here.

 

Most bootloaders I've seen use the first 256bytes of memory, and then continue on with the user program.  If I put the bootloader code at the end of memory, how am I to make sure that the application I generate with C2C won't overwrite the bootloader?  This would mean a custom bootloader, and I would have to use trial/error to figure out how far down into memory I can put the function...not pretty.

 

I think the cleaner, and better solution would be for the user to be able to set what byte ranges are R/O and thus the ORG address.  This allows the linker to determine if there's enough memory or not for your application...AND makes all the existing bootloaders compatible with your compiler.  It seems to me that this would be very trivial to implement since I'm sure all these properties can be directly represented in the assembly you shoot off to the assembler.

 

comments?  various other compilers already support this...to me it seems like a fairly fundamental limitation

Share this post


Link to post
Share on other sites
Guest Pavel
...

Most bootloaders I've seen use the first 256bytes of memory, and then continue on with the user program.

...

This is a very strong statement. Is it based on real figures? Can you provide a list of bootloaders that do use first 256 bytes of memory and a list of others that don't?

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Pavel,

 

Let me explain to you if I really understood your idea.

 

First, I am agreed with your view that it is no relevant where the

bootloader code was placed, but I think that it is reasonable that

the bootloader code would be addressed at the highest part of memory.

Then, in this way, you could easily prevent that the bootloader

code was overwrote by the user code during the download execution.

 

On the other hand, when the user makes his code he will know  that

he should not try to overcome that fixed memory address.

So, he could do what he wants from there up to the bootloader

address starts.

 

Next, there is something that I am worried about.

The bootloader ,that it was written in CC5X, has an only restriction

to the user code.  

The user code must start with this:

 

 

#pragma RESERVE_ADDR_0

#pragma RESERVE_ADDR_1

#pragma RESERVE_ADDR_2

 

 

in order to reserve those addresses to the bootloader code call

 

 

 bsf PCLATH, 3

 bsf PCLATH, 4

 goto _BootCodecode

 

 

 

But just after making a PCLACH correction,  you can make a jump to the

beginning of the user application code.

 

As far as I am concerned, all the description above  have to be made

some considerations, then if you use this method it would be just

moved only the first line of the user application code and the rest of

the code would keep  the same absolute memory position that the user waits.

 

 

C2C bootloader code makes something like this

 

 

0000                  00100         ORG 0

0000   018A           00101         clrf PCLATH

0001   2838           00102         goto startcode

0005                  00107 _nodo

0005   158A           00108         bsf PCLATH, 3

0006   160A           00109         bsf PCLATH, 4

0007   28F1           00110         goto _nodocode

...

...

0038                  00175 startcode

1800   118A           00178         bcf PCLATH, 3

1801   120A           00179         bcf PCLATH, 4

1802   2002           00180         call _BootCode

1803   158A           00181         bsf PCLATH, 3

1804   160A           00182         bsf PCLATH, 4

1805                  00183 _maincode

1805   1283           00185         bcf STATUS, RP0

1806   1303           00186         bcf STATUS, RP1

1807   01E2           00187         clrf _LedOnOff_BootCode

1808   01E3           00188         clrf _LenArray_BootCode

...

...

 

As you see, the addresses over 0x003 are busy with a part of the

bootloader code. But it would have to begin at 0x1800, for example.

From my point of view, the only way to sort this out is to edit the

assembler, delete that intermediate functions call  way and correct

the set pages when it is required.

 

Four your convenience  some references  which I looked into are below,

probably you have read them

 

" Microchip AN732 - Implementing a Bootloader for the PIC16F87X "

 

My code is based on the idea of this document shows, I only wrote down

Assembler code to C code.

 

Regards

Daniel

Share this post


Link to post
Share on other sites

More about bootloader...

 

I was reading Microchip AN851 sheet " A FLASH

Bootloader for PIC16 and PIC18 Devices "

It explain how implement this feature using

the first 256 bytes of memory, but these devices

are factory mades for it.

i.e only PIC16 is PIC16F877A

 

Bye

Daniel

Share this post


Link to post
Share on other sites
Guest you were right

after doing more research it seems most of the bootloaders don't use the top 256bytes, but there seems to be an even number of those that use the top of memory and those that use the bottom of memory.  I'll go ahead and see what the best solution is for my project.

 

Thanks for the help,

 

-Alex

Share this post


Link to post
Share on other sites
Guest Pavel

With a new pragma the compiler from PiAntIDE 5.0 beta 2 now generates bootloader compatible code.

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

I'd like to appologize for my post.  I'm a total newbie to PICs.  After yet MORE research I came to find that the bootloader I was talking about in my first post already worked with C2C.  The thing was that they said the bootloader takes up the top 256 bytes of memory...where TOP = BOTTOM of addressable memory.  URGH...I hate the mix-up of terminology.

 

so in my opinion if if you'd like to remove the new pragma you added feel free to do so!

 

sorry for all the confusion!!  I'm about 50% done implementing my project using C2C.  Uploading my program through the bootloader is quick and easy!!  I have a problem now where I poll portb for input...but I get garbage.  I think I need to set the pull-ups, but when I set bit 7 in the option_reg my program restarts.  I think I may have a fuse misconfigured.  I'll have to look into it later.

 

thanks for all the support!

 

-Alex

Share this post


Link to post
Share on other sites
Guest Pavel
...  After yet MORE research I came to find that the bootloader I was talking about in my first post already worked with C2C...

Which bootloader do you use? Can you post a link?

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Hi

 

I am working with migration bootloader form CC5X

to C2C. I use de #PRAGMA BOOTLOADER xxxx, this

pragma shift all code in xxxx offset. I look two problems:

1 - I can´t put any code at address 0000,0001 and 0002

    but I need this.

2 - I supose that page change doesn´t work propertly

    because all code is in page 4 and I look functions

    call with:

    bcf PCLATH, 3

    bcf PCLATH, 4

    This supose page #0 but it isn´t in fact.

 

Can anybody help me ?

 

Regars

Daniel

Share this post


Link to post
Share on other sites
Guest Pavel
I am working with migration bootloader form CC5X

to C2C. I use de #PRAGMA BOOTLOADER xxxx, this

pragma shift all code in xxxx offset. I look two problems:

1 - I can´t put any code at address 0000,0001 and 0002

  but I need this.

 

Use #pragma RESERVE_ADDR_x to put some instructions on addresses 0-3

 

 

2 - I supose that page change doesn´t work propertly

  because all code is in page 4 and I look functions

  call with:

  bcf PCLATH, 3

  bcf PCLATH, 4

  This supose page #0 but it isn´t in fact.

 

I will release a new compiler version 5.0.5 within couple of days that has this issue fixed

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Thank you, Pavel !!!

 

But don´t understand the fisrt part, because a need

"put" code at address 0000, 0001, and 0002, I use

#pragma RESERVE_ADDRESS in "user code" no in

"bootloader code", bootloader use these address for

absolute jump to bootloader code body.

 

Regars

Daniel

Share this post


Link to post
Share on other sites
Guest Pavel

The RESERVE_ADDRESS pragmas do not depend on the bootloader code. They just tell the compiler to put something on the relevant address. Does this answer your question? (I'm getting impression that we might be talking about different things. Maybe I don't understand your question...)

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Pavel

 

Maybe I don´t know how works RESERVE_ADDRESS,

I believe that i.e. #pragma RESERVE_ADDRESS 0x0 deny

to use address 0x0,  this is useful to reserve some address

 

In fact my problems is that need write from C2C:

 

0000  bsf PCLATH, 3

0001  bsf PCLATH, 4

0002  call BootLoader;   at 0x1800

.....

( here is #pragma BOOTLOADER 0x1800 )

 

1800  BootLoader

.....

 

Excuse my English !!

Regards

Daniel

Share this post


Link to post
Share on other sites
Guest Pavel
Maybe I don´t know how works RESERVE_ADDRESS,

I believe that i.e. #pragma RESERVE_ADDRESS 0x0 deny

to use address 0x0,  this is useful to reserve some address

Not exactly. This pragma not only reserves a code location but also can put a user defined instruction there. For example

 

#pragma RESERVE_ADDR_0 bsf PCLATH, 3

 

will put a "bsf PCLATH, 3" instruction on the address 0

 

Regards,

Pavel

Share this post


Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...