Microchip USB Bootloader?

[chrisj]

Is the MicroChip USB bootloader supported by the MikroC compiler?

This bootloader sits in the bottom 2k of memory, so the compiler needs to relocate above this address - I'm not sure what else it's required to do.

Has anyone got this working?

Thanks
Chris

[teodor]

I'm interested in this myself. I got a pic18F4550 up and running with the MicroChip USB bootloader in the EasyPic4 dev board.

Is it possible to compile with MikroC for this?

Thanks!

[srdjan]

I'm interested in this myself. I got a pic18F4550 up and running with the MicroChip USB bootloader in the EasyPic4 dev board.

Is it possible to compile with MikroC for this?

Thanks!

With some mikroC specific modifications I do not see why not.

[teodor]

With some mikroC specific modifications I do not see why not.

That's interesting. By modifications do you mean that you (MikroE) has to modify the compiler to make it possible or is there some settings I can change?

Thanks again.

[srdjan]

With some mikroC specific modifications I do not see why not.

That's interesting. By modifications do you mean that you (MikroE) has to modify the compiler to make it possible or is there some settings I can change?

Thanks again.

What I ment was that compilers are not 100% compatible, you would have to make slight modifications of microchip's source code in order to compile it with mikroC.

[teodor]

What I ment was that compilers are not 100% compatible, you would have to make slight modifications of microchip's source code in order to compile it with mikroC.

What you mean is actually compiling the boot loader itself, I don't necessarily need that. What I want is to use MikroC to compile programs I can use the bootloader to load.

I have flashed the PIC with the Microchip bootloader HEX file and the bootloader work on the EasyPic board. But can I use MikroC to compile programs? I understand that the compiler needs to remap the reset, low and high priority interrupt vectors, maybe other things aswell?

[srdjan]

What I ment was that compilers are not 100% compatible, you would have to make slight modifications of microchip's source code in order to compile it with mikroC.

What you mean is actually compiling the boot loader itself, I don't necessarily need that. What I want is to use MikroC to compile programs I can use the bootloader to load.

I have flashed the PIC with the Microchip bootloader HEX file and the bootloader work on the EasyPic board. But can I use MikroC to compile programs? I understand that the compiler needs to remap the reset, low and high priority interrupt vectors, maybe other things aswell?

Yes, you can use MikroC, but you'll have to org the procedures above 2k, so the bootloader does not get overwritten by main code. You can do this by orging procedures and functions one by one or by changing the start ROM address in the mlk file of the mcu you are using. Also you would have to at least cut "goto main" instruction at the beginning of the hex file or whole first 2k (of code) of the hex file if the bootloader implementation requires.

[teodor]

I have done some more testing for whatever reason it seems that the MicroChip windows software that is needed to transfer new software does not like the MikroC generated hex file.

The tool from MikroChip show the address map after it loads the hex.

Here is what it looks like when opening this, a MicroChip MPLAB generated hexfile:


Here is what it looks like when opening this, a MikroC generated hexfile:


For some reason the program does not understand the addressing in the MikroC generated hexfile, anybody got any ideas?
Both hexfiles looks ok when opening in PicFlash.

[teodor]

After manually putting in this line: ":020000040000FA" at the top of the hex generated by MikroC the MicroChip USB loader accepted it and I actually managed to compiled and run it.

But I have a few questions.

The MicroChip bootloader jumps to location 0x0800 if not entering "bootmode".
I changed the MLK file under "// ROM MEMORY" to: #pragma SetPage(PAGE0, 0x000800, 0x7FFF)
But the hex file seems to still contain the "goto main" at position 0x0000. That means if the code does not start directly at position 0x0800 it does not work.

So then I changed the MLK file to : #pragma SetPage(PAGE0, 0x000810, 0x7FFF) and manually changed the 0x0000 to 0x0800 in the hex file.

This works, but is it possible to change the MLK file to make the "goto main" start at 0x0800? Or is the only way to manually modify the file?

Thanks

[srdjan]

This works, but is it possible to change the MLK file to make the "goto main" start at 0x0800? Or is the only way to manually modify the file?

Hi,
You can not change mlk file in order to make "goto main" start at 0x0800. Furthuremore, "goto main" is totaly unnecessary so it can be left out of the hex file.
Here is what you could do:
Change mlk file so the ROM starts at 0x0800.
Org main at 0x0800.
In generated hex file find the row with address 0x0800.
Cut everything preceding this line.
Now you hex file should be ready for microchip bootloader tool. Try it.
You can create a tool which could process hex file this for you, so you do not do everything manually.

[teodor]

Hi,
You can not change mlk file in order to make "goto main" start at 0x0800. Furthuremore, "goto main" is totaly unnecessary so it can be left out of the hex file.
Here is what you could do:
Change mlk file so the ROM starts at 0x0800.
Org main at 0x0800.
In generated hex file find the row with address 0x0800.
Cut everything preceding this line.
Now you hex file should be ready for microchip bootloader tool. Try it.
You can create a tool which could process hex file this for you, so you do not do everything manually.

I changed so rom start at 0x0800 and org'ed main to 0x0800 this works fine, only 2 more problems/questions.

1. If I have a C file with interrupt() function it looks like it places this at the ROM start. (Default ROM start is at 0x0008 which is Interrupt vector).

The bootloader requires interrupts to be placed at 0x0808/0x0818. If I try to compile code with interrupt() it will not accept to org main at 0x0800 (Since it probably tries to place interrupt there..)
Anyway I can fix this?

2. Do you know what this line ":020000040000FA" in the hex means? I have to add it to the beginning of MikroC generated hex to make the MicroChip USB loader accept it.
This is the only modification I need to do to the hex now since the USB loader actually ignores everything before 0x0800 I don't need to remove it

[srdjan]

Hi,
This kind of code binding were not really predicted in the compiler, so here is a work around which will allow you to automatically set main and interrupt for microchip usb bootloader.

1. If I have a C file with interrupt() function it looks like it places this at the ROM start. (Default ROM start is at 0x0008 which is Interrupt vector).

The bootloader requires interrupts to be placed at 0x0808/0x0818. If I try to compile code with interrupt() it will not accept to org main at 0x0800 (Since it probably tries to place interrupt there..)
Anyway I can fix this?

The interrupt() function address is orged by the compiler to appropriate address, so you could do the following.

mlk file :

Code: Select all

//ROM MEMORY
#pragma    SetRomSize(32767)
#pragma    SetPage(PAGE0, 0x000808, 0x7FFF)
#pragma    SetPage(PAGE1, 0x000800, 0x830)

code:

Code: Select all

void interrupt(){
  asm nop
}

void main_tread() {

  /*
   * enter your main code here
   */

}

void main () org 0x800 {

   main_tread();

}

2. Do you know what this line ":020000040000FA" in the hex means? I have to add it to the beginning of MikroC generated hex to make the MicroChip USB loader accept it.

That is a type of the Intel hex format records (Extended Linear Address Record). It sets upper 16bits of the 32bit address.

Code: Select all

:     - start of the record
02    - record's data field length
0000  - record's data field storage address offset
04    - type of the record = Extended Linear Address Record
0000  - data field (2 bytes) = upper 16 bytes of the 32bit address 
FA    - records checksum.

Extended Linear Address Record may appear anywhere within a
32-bit hexadecimal object file. This value remains in effect until another Extended Linear Address Record is encountered.
The upper 16bits of the address defaults to zero until an Extended Linear Address Record is encountered. This is why we do not generate this record at the beginning of the hex file.
I can only guess that microchip bootloader was made to expect this kind of record at the beginning of the hex file. We can not help you with this.

[Lucky Luc]

Hi,

I have written a bootloader in delphi (it is almost finished..).
It should be possible to install it as a tool in microC, so it will be possible to download the code direct to the PICDEM board in the MicroC IDE.
As soon it is ready, I will post it.

Luc.

[zristic]

As soon it is ready, I will post it.

Let us know. Thanks.

[motopic]

srdjan: This is the kind of stuff I needed for work with the Sparkfun bootloader.

So I will try a few more things with that. Maybe. Development is much faster using a bootloader to test code. When I get it working I will buy MEC.

We want MEC to support bootloaders of all kinds. Because if we develop products that can be flashed in the field, we don't want our 'end users' to have to buy MEC.

I will get the latest version to test.

Thanks,
Joe