CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Enhanced bootloader

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
iw2nzm



Joined: 23 Feb 2007
Posts: 55

View user's profile Send private message

Enhanced bootloader
PostPosted: Thu Mar 15, 2007 10:20 am     Reply with quote

Hi!

I'm using the Tiny Bootloader (for 16F) and the CCS one (for 18F over RS485) and I'm happy. However, I need more. I'm looking for a bootloader with this features:

1) it should program the CPU after a command sent over RS232/485 during normal run. This to avoid the delay at reset waiting for the command.

2) if the upgrade fails (for example due to a transmission error) it must request a retransmission of corrupted data. In other words it must never fail.

Now the questions:

1) is there any free or pay bootloader (for both 16F and 18F) with these features?

2) If you answered no at previous question I ask you: could I improve the CCS bootloader or there are issues to add these features?

3) When the bootloader is programming the flash, what about the I/O lines? I'd like they don't change.

Thank you!
Marco / iw2nzm
Ttelmah
Guest







PostPosted: Thu Mar 15, 2007 11:00 am     Reply with quote

1), Means this isn't a 'bootloader'...

2), Means that you simply need to add error detection to your code reading the incoming data.

What you need to do, is to have the communication code, and parser, which can detect the incoming serial, and identify the 'program' command, contained in a segment of the chip, which is programmed as 'protected'. This then writes the rest (in a manner like a bootloader), but hands the other serial commands 'on' the the main program. I the event of a programming failure, the program in the PC sending the data, will need to be told to re-send. The system will 'fail', if the data is incomplete, but still be able to be programmed gain (as with a protected bootloader).

Best Wishes
iw2nzm



Joined: 23 Feb 2007
Posts: 55

View user's profile Send private message

PostPosted: Thu Mar 15, 2007 11:39 am     Reply with quote

Ttelmah wrote:
1), Means this isn't a 'bootloader'...


Yep! Razz

Quote:
2), Means that you simply need to add error detection to your code reading the incoming data.

What you need to do, is to have the communication code, and parser, which can detect the incoming serial, and identify the 'program' command, contained in a segment of the chip, which is programmed as 'protected'. This then writes the rest (in a manner like a bootloader), but hands the other serial commands 'on' the the main program. I the event of a programming failure, the program in the PC sending the data, will need to be told to re-send. The system will 'fail', if the data is incomplete, but still be able to be programmed gain (as with a protected bootloader).


Ok, I understand.

Well, it seems I only need to write the communication, parser and reprogram code in a defined segment of the flash and protect it.

I use interrupt to detect incoming data so I have to do something like this:

Code:


#ORG ****


#int_rda()
void  RDA_isr(void) {
   char rcv;

   rcv = fgetc(PC);
   
   if (rcv == RST) load_program();
}

void load_program {...}

#ORG ****

#int_timer0() { ...}

void main() {...]



Is it right? If so I ask you: how I may select the correct ORG address? How I can protect from writing only that segment of code?

Thank you for your patience!

Marco / iw2nzm
Christophe



Joined: 10 May 2005
Posts: 323
Location: Belgium

View user's profile Send private message

PostPosted: Fri Mar 16, 2007 1:49 am     Reply with quote

remember that using interrupts in your bootloader is hard.. even as writing your own botloader.. just don't invent the weel..
iw2nzm



Joined: 23 Feb 2007
Posts: 55

View user's profile Send private message

PostPosted: Fri Mar 16, 2007 3:37 am     Reply with quote

Christophe wrote:
remember that using interrupts in your bootloader is hard.. even as writing your own botloader.. just don't invent the weel..


No, I don't want to use interrupt inside the loader routine. I just use interrupt during normal run to receive serial data. If I receive the "load command" I call the loader routine which disables interrupts and manages the communication like the CCS bootloader example.

My difficult is how to select the correct ORG directive for both normal run and loader function in order to guarantee to reprogram the flash even if there was errors during code transmission.

Regards
Marco / iw2nzm
KaraMuraT



Joined: 16 May 2006
Posts: 65
Location: Ankara/Turkey

View user's profile Send private message Send e-mail

PostPosted: Fri Mar 16, 2007 4:18 am     Reply with quote

You can do this that way:

If you're using a PIC which has EEPROM, and your main application is running, parse your incoming data and if you get an valid bootload command, write a certain EEPROM byte a valid character like "0x23" at address 0xFF, and than use goto_address(BOOTLOADER Reset). Don't use reset_cpu because it will simply jump to your normal application start.

Than your bootloader can check this byte whether a bootloading requested or not. If 0xFF address of EEPROM is 0x23 than starts receive process. Than passes control to application. The application starts and before while(1) loop it sets this eeprom area to a different value like 0x00 or 0xFF.

If somehow a hardware reset or startup occures yoru bootloader will heck this byte and pass the control directly to application in a blink time. No one will get hurt Wink

But there is a problem... about power consumption. If you use this kind of approach and cannot download a valid application code after restart, your PIC will hold awake, and will consume power continuously.

That's the point where the bootloader interrupts enters the scene...
_________________
/// KMT
/// www.muratursavas.com
iw2nzm



Joined: 23 Feb 2007
Posts: 55

View user's profile Send private message

PostPosted: Fri Mar 16, 2007 4:39 am     Reply with quote

[quote="KaraMuraT"]You can do this that way:

If you're using a PIC which has EEPROM, and your main application is running, parse your incoming data and if you get an valid bootload command, write a certain EEPROM byte a valid character like "0x23" at address 0xFF, and than use goto_address(BOOTLOADER Reset). Don't use reset_cpu because it will simply jump to your normal application start.

Than your bootloader can check this byte whether a bootloading requested or not. If 0xFF address of EEPROM is 0x23 than starts receive process. Than passes control to application. The application starts and before while(1) loop it sets this eeprom area to a different value like 0x00 or 0xFF. [\quote]

Why?

When I parse the incoming data and, get a valid loader command and call the loader function (without reset_cpu() ) I don't need a further condition to start writing process. Simply I need to hard code the loader function into a well defined area of the flash. Another user did the same ("Bootloader and PCW compiler: memory mapping") but I can't understand where and how write ORG directives.

[quote]
If somehow a hardware reset or startup occures yoru bootloader will heck this byte and pass the control directly to application in a blink time. No one will get hurt Wink [\quote]

Ah, maybe I misunderstood your previous tip: writing in the EEPROM a byte when a new code is going to download guarantees the system doesn't hang also in the case of errors during programming, isn't it?

Quote:
But there is a problem... about power consumption. If you use this kind of approach and cannot download a valid application code after restart, your PIC will hold awake, and will consume power continuously.

That's the point where the bootloader interrupts enters the scene...


No problem at all about power consumption! I only need the PIC never hangs!

Bye,
Marco / iw2nzm
KaraMuraT



Joined: 16 May 2006
Posts: 65
Location: Ankara/Turkey

View user's profile Send private message Send e-mail

PostPosted: Fri Mar 16, 2007 5:11 am     Reply with quote

Yes... Thats for it. And for making it rock solid do this:

Activate Watch Dog Timer for enough time like 1 s intervals. and reset the WDT for every buffer process. This helps you about interrupted bootloadings about communication errors.
_________________
/// KMT
/// www.muratursavas.com
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group