| View previous topic :: View next topic |
| Author |
Message |
EdWaugh
Joined: 07 Dec 2004
Posts: 127
Location: Southampton, UK
|
|
 Posted: Fri Oct 23, 2009 10:39 am |
 |
|
Hey Ryan,
I think this symptom means that something is going wrong. The loader should not be using the fprintf/fputc functions from your main code it should be using the ones setup inside its allocated space by the #use rs232 statement within the #org.
Did you manage to get it working this way as well?
cheers
ed |
|
 |
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Fri Oct 23, 2009 3:59 pm |
|
|
| EdWaugh wrote: | Hey Ryan,
I think this symptom means that something is going wrong. The loader should not be using the fprintf/fputc functions from your main code it should be using the ones setup inside its allocated space by the #use rs232 statement within the #org.
Did you manage to get it working this way as well?
cheers
ed |
I realized this after I posted last night - I don't have the #use rs232 statement in the #org section. I'm sure that's why.
I can get it to work correctly once, and the code appears to run great upon restart. But when I try to load new code again, something isn't working right. I haven't had much time to play with it today, but I'll let you know how it goes. |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Fri Oct 23, 2009 4:58 pm |
|
|
Ed,
Will you please tell me what you looked for specifically in the list file to determine if the code in the #org section was using resources outside of this region? The writing of program memory is halting after only writing a little bit.
Thanks,
Ryan |
|
|
evsource
Joined: 21 Nov 2006
Posts: 129
|
|
| Posted: Sat Oct 24, 2009 6:49 am |
|
|
| evsource wrote: | Ed,
Will you please tell me what you looked for specifically in the list file to determine if the code in the #org section was using resources outside of this region? The writing of program memory is halting after only writing a little bit.
Thanks,
Ryan |
I decided the instructions of interest were calls and goto's. I just looked through the address space of the #org area for the loader, and made sure no call or goto went to some space outside of that.
A couple other notes for anyone that attempts some modification to the loader code, either the code listed in this post by Ed, or the original code by CCS:
1) The printf's were extremely helpful throughout the loader code itself for debugging. You have to put the #use RS232 statement inside the #org section for it to work though.
2) All functions used in the loader section of your code *have* to reside in the #org section. I found there were a few ways to do this, all which seemed to work. The first is to just make a copy of the functions required into the #org section. This requires naming the function something different than what is used in the main program. Sort of a pain I found. Another is to just place the functions in the #org section only - meaning your main code accesses the functions from the #org section. This also means that these functions will not be modified as your code evolves over time and you reprogram the chip through the loader. I didn't like that implication. So, I tried making the functions used in the #org section #inline'd. That means the compiler will place a copy of the functions in the #org section - in fact, it will place a copy of the function anywhere the function is called in your code. Although this acts to speed up the code, it also bloats the code quite a bit. I went from using 27% of ROM with the 2nd option I suggested above (placing the functions only in the #org section) to 42% when #inline'd. The only other problem with this method is that it requires changing the functions you are using. If you are using a 2nd party library of code, if/when you receive updated code, you'll always have to go through and add the #inline statements. Ed also suggested it's possible that the compiler will ignore your request to have the function placed inline, which would spoil this method. Even with those implications, at this point, I prefer the #inline option. It means that as my code evolves, I can change my communications functions that will be used in my main program. Yes, the communications functions (or any other type of functions) used in the loader code will not evolve as the changes are made. But, for what I am doing, I just need the core communications functionality in place for the program loading to work.
So, in summary, there are several ways to add your own custom functionality (communications, etc.) to this nifty loader code that provides you with the ability to load a new program onto the chip over a communications line of your choice. No single method is without drawbacks - they all have their strengths and weaknesses. But isn't that how everything is in life? |
|
|
jesconsa
Joined: 21 Jun 2010
Posts: 3
|
|
| Posted: Mon Jun 21, 2010 6:08 am |
|
|
| Try to put WRT on the FUSES!!!..It works for me!!!!. Ciao. Jesus. |
|
|
cassioriguela
Joined: 25 Oct 2011
Posts: 27
|
|
| Posted: Tue Oct 25, 2011 6:44 pm |
|
|
Hello Ed,
I'm studying your code and i have a doubt:
The user code (after bootloader function to be programmed by icd3) needs contain bootloader function ?
Thanks! |
|
|
cassioriguela
Joined: 25 Oct 2011
Posts: 27
|
|
| Posted: Thu Oct 27, 2011 5:34 am |
|
|
After some hours studying it. I think I'm able to do it now. But I still have one doubt:
If my system get off when the new code is going to my microcontroller. What will it happen ? Bootloader will response again ?
Thanks guys. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
