Boot Loader with 18LF2620

BLL · Joined: 11 Nov 2006 Posts: 181 Location: Birmingham, UK

Hi
I have not used the idea of a boot loader before. I have downloaded and installed the Microchip software, P1618QP.exe.
First problem: I am using COM16 to communicate with the PIC. It works. However, when I edit the .ini file to say portIndex=16 and then run the exe, it says: Core error: Control array element '16' does not exist. I can't alter the port to a lower value in Device Manager as all are marked as in use. I have tried ascending numbers and these show as COMx in the exe, up to COM4. After that, I get the error. How can I get the program to recognise my com16?
I am using Win7 32 bit Home.
If that hurdle can be overcome, what fuse settings do I need to protect the boot loader code?
Also, the device list doesn't show any LF devices - do I presume this doesn't matter? I am using an 18LF2620 on 3.3V.
Is there anything else I need to know/do please?
Any help much appreciated.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

BLL · Joined: 11 Nov 2006 Posts: 181 Location: Birmingham, UK

Hi both respondents
Since the post, I have also tried CCS's offering, editing bootloader.c for the 18F2620, compiling it and programming it into my PIC. However, when I then run compiled loader.c, it goes so far and then says the PIC is not responding!
The debug file shows that some hundreds of locations have been programmed, but by no means all.
I have tried reducing the baud rate - no better.
I have tried a FTDI USB serial converter instead of my pl2303 one - no better.
It just seems so flaky and unreliable. Does the technique of boot-loading work at all?
I don't know what to do next!

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

BLL · Joined: 11 Nov 2006 Posts: 181 Location: Birmingham, UK

No, I am not using siow, but the program CCS provide. Yes, I have set xon/xoff control. Yes, I did edit both the files you mention. changed the device to 18F2620 and confirmed that the 232 parameters were correct. Set A5 as the pin to detect reload or normal boot.

Brian

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

It is important to understand that the CPU effectively has to stop working when it programs it's own ROM.

This is why flow control (as PCM_programmer points out), is vital. The bootloader has to be able to stop the incoming data while a block is written, and then start it again to receive the next block.

Bootloader's work fine. Many people here have used them, but you have to set things up correctly to use them.

If you read the comments, in loader.c, you will find that it tells you it uses XON/XOFF, and looking through the file you will see that it stops transmission using XOFF, before it writes, and then turns it on again afterwards. Your comm port needs to be setup to do this.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

jeremiah · Joined: 20 Jul 2010 Posts: 1349

I have the IDE version and it is SIOW.exe for me as well.

BLL · Joined: 11 Nov 2006 Posts: 181 Location: Birmingham, UK

Hi all
I am still getting nowhere with this. In case I am doing something stupid, here is what I have done:

1). Modified ex_bootloader.c for 18F2620 and 10MHz oscillator:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Make sure you have this circuit on pin A5:

BLL · Joined: 11 Nov 2006 Posts: 181 Location: Birmingham, UK

Hi, both respondents. Pin A5 has a 13K pullup resistor to +3.3V and a switch to ground. I have double checked with a meter that the pin is at 3.3V with the switch open and 0V, when closed.

I tried tera term and I thought that had cracked it, but alas no!
It starts transferring bytes very slowly and stops at 3% (2895 bytes). The transfer speed is a lightning 181 bytes/sec!! It then just stops. Worse, if you exit tera term and try again or use any app which uses com14, tera term says com14 is not available. The other program I use says access denied. The only solution is to reboot and then you get one chance, which stops at 3.4% and mucks up the port!!

I emphasise that if I load my app straight into the PIC, it works and so does the serial port without problems!

I just don't know what to do next!

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

Whoa a sec.

An application compiled for use with a bootloader, _should not work if loaded directly into the PIC_. It _requires_ the relocation components contained in the bootloader to actually work.

It rather suggests to me, that you are not correctly compiling the application to use the bootloader.

Look at ex_bootload.c
This shows how the application needs to be compiled to load with the bootloader.

If you try to load an application built to load at the bottom of memory, with the bootloader present, of course it will fail. It can't write to the area where the bootloader sits.....

Ttelmah · Joined: 11 Mar 2010 Posts: 19515

You should not jump off onto another thread.

You are missing the point. I do not refer you to ex_bootloader.c. I am pointing you to ex_bootload.c

Note the lack of the 'er'. Big difference.

ex_bootloader.c, is the bootloader.

ex_bootload.c, shows you how to compile your program to load with the bootloader.

You need to compile your program like this (note the change in the #define from bootloader.c, and that it still includes the .h file to relocate the code).

A normal program will _not_ load with the bootloader. The program itself needs to be compiled with the settings to work with the bootloader. If your program loads and runs when programmed normally, it is _not_ suitable for use with the bootloader.