View previous topic :: View next topic |
Author |
Message |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Dec 09, 2009 2:07 pm |
|
|
Someone once PM'ed me about how to make the CCS bootloader
example work. I don't normally like to do answers in PMs but I made
an exception in that case. I'll post my answer to him below.
Basically, the problem turned out to be that some versions of SIOW
simply don't work with the CCS bootloader. I don't know which versions
work. But TeraTerm does work. Here's my reply to him:
----------
I finally got the CCS bootloader example to work (i.e., download and
run the application) by using TeraTerm instead of Siow.
TeraTerm installation instructions:
http://www.ccsinfo.com/forum/viewtopic.php?t=39388&start=18
Go to the Setup/Serial Port menu in TeraTerm and select Com1, 9600,
N, 8, 1 and set Flow Control to XON/XOFF.
Compile Ex_bootloader.c, and program the .HEX file for it into your
18F452, by using your ICD2 from within MPLAB.
Compile Ex_bootload.c (This is a different program than Ex_bootloader.c).
Then jumper PIC pin B5 to ground on your board (and leave it jumpered).
Press the PIC's reset button on your board. (Disconnect the ICD2 before
doing this, and leave it disconnected). The 18F452 will go into the mode
where it's expecting to receive the application program's HEX file.
This is Ex_bootload.hex (NOT Ex_bootloader.hex).
Then go to the File menu in TeraTerm and click on Send File. Select
the Ex_bootload.hex file. If you double click on the .Hex file, it will
be sent automatically, almost instantly, and the output will start
appearing in the TeraTerm window. The expected output from
Ex_bootload.hex is a bunch of continuously incrementing numbers.
If you must use your 18F4685 PIC, then make as few changes as
possible to the CCS example files. I think you may be able to just
change the #include file in both Ex_bootloader.c and Ex_bootload.c.
-----------------
Edit: Fixed a minor spelling typo.
Last edited by PCM programmer on Mon Nov 16, 2015 2:39 pm; edited 1 time in total |
|
|
nilsener
Joined: 06 Dec 2005 Posts: 59
|
|
Posted: Wed Dec 09, 2009 2:42 pm |
|
|
Dear PCM,
thank you very much for your quick answer. I don't want to use SIOW or TeraTerm or something like that later for my application. Later the bootloader should load the program memory of an other chip that contains the actual software via serial communication. My problem is to understand where to insert all the statements in order to add the bootloader to my maincode. Can you supply me with this basics? If one will be so kind to insert
the statements into my sample code I can evaluate it step by step to understand what is going on.
Thanks for helping
nilsener |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Dec 09, 2009 3:32 pm |
|
|
The problem is, in order to give an answer, I would have to go do the
project. I don't have time to do that right now. I could maybe do it
during the weekend. I can't promise anything. Hopefully someone
else has already done it and can help you. |
|
|
nilsener
Joined: 06 Dec 2005 Posts: 59
|
|
Posted: Thu Dec 17, 2009 4:23 am |
|
|
Hello,
Darren from CCS told me that I just need to #include <bootloader.h> and <loader.c> in my application and it compiles now.
As I make the software update not with SIOW but from another PIC, I have to modify the loader.c. How can I determine the starting address in program memory, where the compiler places my main application?
I found this in bootloader.h:
Code: | #define LOADER_END 0x4FF
| Is the starting address of my main application then LOADER_END+1?
I found this in loader.c:
Code: | #define LOADER_END getenv("PROGRAM_MEMORY")-1
| Does it mean, that getenv("PROGRAM_MEMORY") gets the starting address of the main application and LOADER_END is on top of it?
Best Regards
nilsener |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Dec 17, 2009 3:01 pm |
|
|
Quote: |
I found this in loader.c:
#define LOADER_END getenv("PROGRAM_MEMORY")-1
Does it mean, that getenv("PROGRAM_MEMORY") gets the starting address of the main application and LOADER_END is on top of it?
|
But that line has an #ifndef statement before it:
Quote: |
#ifndef LOADER_END
#define LOADER_END getenv("PROGRAM_MEMORY")-1
|
Darren told you to include bootloader.h, and if you look in that file,
it defines LOADER_END. So, the #ifndef doesn't apply. The getenv()
statement won't be used. The #define statement for LOADER_END
in bootloader.h will be used instead. |
|
|
nilsener
Joined: 06 Dec 2005 Posts: 59
|
|
Posted: Fri Dec 18, 2009 8:56 am |
|
|
Hello PCM,
ok, I understand.
The compiler places the Bootloader to the #org defined rom space then.
But where does the compiler place my main application, is it LOADER_END+1?
Best Regards
nilsener |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Dec 18, 2009 2:48 pm |
|
|
A simple way to test this, would be to compile a very small application
program. Then download it into the PIC. Then use your programmer
to read the PIC. Look at the Program Memory window (assuming you're
using MPLAB) and visually compare it to the .LST file for your application.
By doing that, you can find the address in the Program Memory window
where your application has been loaded. |
|
|
|