Bootloader questions with dsPIC30F6014A

[naughty_mark]

Hi everyone,

I just got bootloader code successfully running on my dsPIC30F6014A chip with CCS compiler version 5.016. As I searched in this forum, I use Tera Term to send hex file. But I have a problem:
After I downloaded my program into the chip, I re-powered up my system, the bootloader gone and the program runs my main program directly.
I am not surprised to it, because even I use #ORG statement to specify the ROM address in my main program is from 0x0602 (0x0100 to 0x05FF used for bootloader code), there is still some code compiled in the address 0x0000 to 0x00FE, and I know that is reset vector address and interrupt vector, and I think the reset address is changed to my main program entry address not the bootloader program entry address.
So my question is:
1. what should I do to let my program always start from bootloader entry address without changed by downloading the main program hex file?
2. If the first question gets solved, How do I know my main program entry address in the ROM? I tried to use #ORG 0x0602 before the main function in my main program code, but the compiling not pass, because I think the compiler can not put my whole program in to section from 0x0602 to 0xFFFE. So my question is how do I define my main function entry address in main program code so that I can use this address to let bootloader know where is to entry if bootloader not triggered by external input?

Thanks for you guys help!

Kind Regards
Mark

EDIT: I use CCS bootloader example code as my bootloader program in this project with some address changes

[jeremiah]

Unless you reassign the reset and interrupt vector table using the #build command in your application, it will still put things there. I know you mentioned #ORG, but did you block out the full range?

I usually start my apps with

[naughty_mark]

[jeremiah]

You can just #define the location of the application reset vector in the bootloader and use goto APPLICATION_RESET_VECTOR_LOCATION



The main thing is the bootloader needs the application reset vector defined and jumped to and the application needs the #build(reset=APPLICATION_RESET_VECTOR_LOCATION) so that they agree. The rest can be handled by the compiler.

[naughty_mark]

[naughty_mark]

Hi jeremiah, I just tried your way, but it doesn't work, the code I put in my application is:

[jeremiah]

You have to spell build correctly!

[naughty_mark]

[naughty_mark]

I passed the compile and I am trying to download and see the result.

However, I doubt it will ok because after compiling my application I check the hex file, the first line is still about some content in address 0x0000 which will change the reset vector that should point to bootloader entry address. However, in my bootloader code, if the chip gets 0x0000 address to write, it will skip, so won't effect

Mark

[jeremiah]

That's because your #org starts at 0x0100 instead of 0x0000. Normally CCS won't put any real code there because the reset is there. Since the reset is moved it might unless you make sure #org prevents it.

Since you are leaving in the IVT but moving the reset, you'll need to #org around the IVT:

#build (reset = 0x0800)
#org 0x0000,0x0001 {}
#org 0x0100,0x07ff {}

Notice I also changed the values. You don't want to start mid Page as you have to erase an entire page at a time to write to it. You don't want to erase part of your bootloader. Always start on page boundaries.

EDIT: On that note, I'm not as familiar with that particular chip, but you might run into problems letting the application write to 0x0002-0x00ff for the interrupts. Once the bootloader is burned in, you can only write to that location once without reprogramming the bootloader again (remember have to erase on page boundaries but you don't want to erase the first page since your bootloader reset vector is there). Something to consider. On my bootloaders, I generally move both the reset vector and the IVT out of there so my app can use interrupts without having to reprogram the bootloader again.

EDIT: I also just noticed that you put FUSES in the application. This is generally a bad thing to do. If you change the fuses from what the bootloader uses, you can sometimes mess up the bootloader. If your bootloader ignores these it is ok, but I like to make sure to use

#FUSES NONE

In my application code.

[naughty_mark]

[jeremiah]

How are you verifying that it didn't go to the application? What's your means of debugging available?

I'm still concerned about your 0x0900 address. Normally you would want to start on a page boundary (I'd have to look it up in the data sheet, but I think multiples of 0x0400 maybe? If so, you would either want 0x0800 or 0x0c00).

[naughty_mark]

[jeremiah]

Yes, if that is the erase size, you are good. I'm more familiar with other PCD chips, so I wasn't sure. On mine, flash erase size comes out to 2048, which is 1024 words or 0x0400. I typically use PIC24's though.

The reason I was asking about the debugging method was I was curious where it was failing.

I think the safest thing to do is that if your other method you mentioned earlier works, stick with that. I know my method works too (at least on my projects so far), but don't know where in between the issue cropped up. I don't want to hold you up trying to change everything and end up having you chase down a lot of problems.

[naughty_mark]