| View previous topic :: View next topic |
| Author |
Message |
ajt
Joined: 07 Sep 2003
Posts: 110
|
| Relocate putc() or write my own for bootloader? |
 Posted: Mon May 16, 2011 3:41 pm |
 |
|
I have a stock version of the CCS supplied loader.c (drivers folder) running (sort of) on a 18F2420. The application is set up exactly like ex_load.c only much larger.
I am loading the bootloader into high memory. Everything proceeds along when flashing a file until it hits the the same exact spot where it blows up.
I must be missing something right in front of me since I assume other people are successfully this bootloader. The problem as I see it is that loader.c uses putchar() and it is located in user code space not the bootloader segment. When downloading a hex file I can get to address 0x0b40 before it bombs at the next line in the hex file. Interestingly, putchar() is located at 0x0B64!
| Code: |
01685 .................... #use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8, stop=1)
0B64 A89E 01686 BTFSS F9E.4
0B66 D7FE 01687 BRA 0B64
0B68 6EAD 01688 MOVWF FAD
0B6A 0C00 01689 RETLW 00
|
Here is an example of a call to putchar() in my loader code:
| Code: |
02199 .................... putchar (ACKLOD);
3D9A 0E06 02200 MOVLW 06
3D9C ECB2 F005 02201 CALL 0B64
|
As a test I tried rearranging things to get putchar() to be at a different location and the symptoms are the same just at a different place in the hex file corresponding to the new location for putchar().
How can this ever work? I want to try to relocate putchar() or write my own version to put in the bootloader segment. Any tips on how to do that (or what I am doing wrong in my example)?
_________________
Al Testani |
|
 |
ajt
Joined: 07 Sep 2003
Posts: 110
|
| Relocate putc() or write my own for bootloader? |
| Posted: Mon May 16, 2011 7:00 pm |
|
|
Well, I answered my question but still don't understand how anyone has gotten loader.c to work. BTW, I am using v4.119.
I added the following to my loader code:
| Code: |
//----------------------------------------------
void p_putchar(char c)
//----------------------------------------------
{
#asm ASIS
loop:
BTFSS 0xF9E.4 // PIC18F
BRA loop
MOVWF 0xFAD
#endasm
} |
and everything works fine now as expected. So what is going on here?! Has anyone been successful in making the loader.c code supplied by CCS work unmodified?
_________________
Al Testani |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19535
|
|
| Posted: Tue May 17, 2011 2:26 am |
|
|
Normally loader.c, as supplied, correctly puts _it's_ putchar, into _it's_ memory space. I'd suspect some tiny part of the changes you have made to it, are resulting in it using the 'main' putchar instead.
Best Wishes |
|
|
ajt
Joined: 07 Sep 2003
Posts: 110
|
|
| Posted: Tue May 17, 2011 8:03 pm |
|
|
| Ttelmah wrote: | | Normally loader.c, as supplied, correctly puts _it's_ putchar, into _it's_ memory space. I'd suspect some tiny part of the changes you have made to it, are resulting in it using the 'main' putchar instead. |
The only changes I made were to turn on a couple of LEDs for each memory write and also when real_load_program is entered. I tried a test with loader.c *exactly* as provided by CCS and had the same problem of the hang when it overwrote the putchar code in application memory space.
It appears from reading the #ORG description that the keyword DEFAULT is supposed to do what you say but it is not as far as I can tell. Maybe this is a bug in the compiler? Unless the application program is reasonably large this problem will not manifest itself. The example application using loader.c is tiny so maybe it has been missed.
Has anyone with a large application been able to make loader.c work as advertised?
_________________
Al Testani |
|
|
ajt
Joined: 07 Sep 2003
Posts: 110
|
|
| Posted: Thu Jun 02, 2011 1:40 pm |
|
|
To close out this topic here is my final "report".
I put this into a bug report to CCS. At first CCS Support came back with a response about the ordering of #org and #use RS232. I pointed out that this was in fact how their example and my example were written but it just doesn't work.
After the second iteration CCS Support said:
| Quote: |
We will be updating our examples. The code works either way with a simple RS232 but for many configurations the RS232 functions must be inside the ORG.
|
I don't understand what could be simpler than their example and still think it is a bug as the ORG with default keyword doesn't work as the manual states. In any case, other people won't have the big hassle I did on this since the examples are being fixed.
BTW, I asked if CCS still gave a free update when a bug was found and the response was:
| Quote: |
We give free updates when someone finds a bug where there is not an easy work-around.
|
Huh?
_________________
Al Testani |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
