CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com
Interrupt Vector Remapping - HID Bootloader - 18F4550
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
cjc
Guest
Interrupt Vector Remapping - HID Bootloader - 18F4550
PostPosted: Tue Apr 28, 2009 10:05 am     Reply with quote
Greetings -

I have spent a fair amount of time trying to get this to work properly, with varying results.

I'm using the PICDEM FS USB board (18F4550) and trying to use the Microchip HID bootloader.

The test applications work fine, and I can compile, load, and execute my own but I'm running into a problem which I can only assume has something to do with the remapping of the initial vectors.

Code:

#include <c:\Program Files\PICC\Devices\18F4550.h>

#build(reset=0x1000, interrupt=0x1008)
#ORG 0x0000,0x0FFF {}
void bootloader()
{
#asm
nop
#endasm
}

#FUSES HSPLL, NOWDT, NOPROTECT, BROWNOUT, BORV28, NOPUT, NOCPD, NOLVP, LPT1OSC, NOMCLR, NOPBADEN, USBDIV, PLL5, CPUDIV1, VREGEN
#use delay(clock=48000000)


All this seems to work well and good, but the problem that I'm having is odd. (I can post the full code if necessary)

The general issue is this: I have Timer1 setup as an RTC and using the Port B interrupt for rotary encoder. I also am using the flex_lcd driver and RS232 for feedback.

Stand alone (without using the remapping statements) a simple test program using these functions work fine. I can also build a simple test program using the remapped vectors and memory organization. The problem starts when I begin to add the rest of the program.

I have observed that if I take the bootloaded test program that works fine, and begin to add functions with static and global variables, it stops the LCD from displaying data and seems to kill all but the Timer1 interrupt as I can see a counter incrementing through the UART.

My gut feeling is that for some reason the initial interrupt vectors aren't being mapped correctly as there is a high and low priority and the code above doesn't address both (it'd seem) I looked through the assembly and it looked to confirm this.

I feel this is a trivial problem that my fried brain is missing; any input would be greatly appreciated.

Best regards,
-Chris
cjc
Guest
PostPosted: Tue Apr 28, 2009 5:31 pm     Reply with quote
Anyone? I'm even willing to pay someone to shed some light on this ;)
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Apr 28, 2009 5:42 pm     Reply with quote
The Flex_lcd driver is not designed for #fast_io mode. Are you using
that mode ?

You can trouble-shoot it by re-directing the output of lcd_putc() to the
hardware UART. (Or use a software UART). View the output on a
terminal window in your PC. See if you still get output when the whole
lcd driver is bypassed.

Comment out the flex driver line:
Code:
//#include "flex_lcd.c"


Add the substitute routine below. Also add the #use rs232() statement
for the putc().
Code:
void lcd_putc(int8 c)
{
putc(c);
}


Comment out the lcd_init() at the start of your main()
Code:
//lcd_init();


Comment out any calls in your program to other Flex driver functions,
such as lcd_gotoxy():
Code:
//lcd_gotoxy(1, 1);


This will tell you if the LCD code is a problem. It could be because the
code is not being written to flash properly. In which case, this re-direction
of output may not even work. But at least you have a chance to have
serial output with the changes above.
Guest
PostPosted: Tue Apr 28, 2009 5:58 pm     Reply with quote
Thanks for the response PCM.

This very well may be the problem. All functions but the LCD work, which is what I had seen previously. I left in all of the flex_lcd related commands, but had some of the data copy out to the UART. It all is correct, and all interrupts are firing as expected.

The display is just blank, and until I remove the majority of the functionality and go back to a basic program, it stays this way.

Any additional advice?

-Chris
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Apr 28, 2009 10:52 pm     Reply with quote
You need to verify if the application is entirely being written into flash
memory by the bootloader code.
Guest
PostPosted: Tue Apr 28, 2009 11:00 pm     Reply with quote
As far as I can tell, by checking all aspects of the application, it's all being written. I can dump to the UART everything the LCD should be displaying without an issue and all other aspects are working fine.

I've also tested using the CCS driver using the write to port (D).

I'm still taking shots in the dark, but it's becoming rather frustrating...
cjc
Guest
PostPosted: Wed Apr 29, 2009 4:35 pm     Reply with quote
Further update...

I have it to a point now where omitting a fair amount of the printf statements throughout the application related to the LCD will keep the unit running.

Interestingly enough, I can put a lcd_putc into places where printf is commented out and it will work.

With this knowledge, I'm still stumped. The program, aside from not displaying on the LCD as expected, is working perfectly.

Anyone else on this? Please :-)

-Chris
cjc
Guest
PostPosted: Thu Apr 30, 2009 1:27 pm     Reply with quote
Further updates...

I've now tried the CCS CDC USB bootloader with success, and when loaded directly, everything works great.

For some reason, regardless of what LCD driver tried, it simply isn't displaying as expected (or anything for that matter) The rest of the application executes flawlessly.

I'm sure this is a trivial thing, but it's escaped my sight. I'm running out of time on this project, and getting nowhere by staring at it.

If anyone else has some input and experience with this, please let me know. Again, I'm happy to pay for a consultation to get this taken care of.

Best regards,
-Chris
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Apr 30, 2009 1:51 pm     Reply with quote
1. What pins are you using for the LCD ? Do they interfere with the
USB bootloader pins ? Make sure no USB pins are used for the LCD.

2. Are you using interrupts ? Try adding lines to the LCD driver code to
disable global interrupts when the LCD routines are executing.
See if that helps.

3. The LCD driver uses some CCS library code for the delay functions.
It's possible that there is a conflict with the bootloader because of this.
Try to fix this by creating a 2nd instance of the delay functions.
This is done by adding another #use delay() statement. Example:
Code:
#include <16F877.H>
#fuses XT, NOWDT, NOPROTECT, BROWNOUT, PUT, NOLVP
#use delay(clock=4000000)   // Delay code for flex_lcd.c driver

#include "flex_lcd.c"

// Create a 2nd instance of the CCS Library code for calls to
// delay_ms() and delay_us() which are below this point.   
#use delay(clock=4000000) 
//====================================
void main()
{
lcd_init();

lcd_putc('A');

delay_ms(10);

while(1);
}
cjc
Guest
PostPosted: Thu Apr 30, 2009 2:22 pm     Reply with quote
1. Using port D; the only thing the bootloader uses on this port are indicators. The switch to enter bootloader mode is PIN_B4. This doesn't seem to be the issue though, as I can run a stripped down version of the code and it's fine, but when it's in full version it takes a dive.

2. Tried, no change.

3. Tried, no change.

Thanks for your input PCM - anything else is greatly, greatly appreciated.

-Chris
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Apr 30, 2009 2:27 pm     Reply with quote
Put a logic analyzer on all the LCD pins. Run it with your standalone
application to get a baseline result. Run it with your bootloaded code
to get the test result. Compare the two.

Here is a good low-cost USB Logic Analyzer, the LA1034:
http://www.pctestinstruments.com/
cjc
Guest
PostPosted: Thu Apr 30, 2009 2:58 pm     Reply with quote
Using a logic analyzer, I found that the RS and E lines are the only ones actually changing after loading and repowering. (When loaded for the first time, the D4-47 lines act chaotically with jumbled readout)

I saw this originally crudely using a scope. It is indeed very odd...

I added a four output_toggle commands for the pins these are on, and it does indeed toggle as expected, but the LCD related command isn't hitting them.

I'll continue to break down and see...

-Chris
cjc
Guest
PostPosted: Thu Apr 30, 2009 3:39 pm     Reply with quote
A bit more...

Complete random chance allowed the whole program to upload and work, once. To see if it was just luck I pulled the power, and restarted and ended up back in the same place. All that's strobing are the enable and RS lines.

It seems like something is changing the parameters of the port, but there's nothing else accessing these ports but the LCD driver.

Also - I've commented out the bootloader's use of port D. Didn't seem to make a difference (though I didn't expect it to)

-Chris
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Apr 30, 2009 3:48 pm     Reply with quote
1. Post the list of #define statements for the Flex_lcd.c driver. Also post
the #define for USE_RW_PIN (to show me if it's commented out or not).

2. Post your LCD manufacturer and part number.

3. Post if you are using Fast i/o mode or Fixed i/o mode on any ports.
These are done with #use statements.

4. Post if you are doing any kind of two-speed oscillator operation.
Are you running the program at one speed initially and then changing it ?

5. Post the actual Config Bits that are in effect when your program is
running. I assume that the bootloader's Config Bits are the ones in
effect. What are they ?
cjc
Guest
PostPosted: Thu Apr 30, 2009 6:12 pm     Reply with quote
1)
Code:

#define LCD_DB4 PIN_D4
#define LCD_DB5 PIN_D5
#define LCD_DB6 PIN_D6
#define LCD_DB7 PIN_D7

#define LCD_E PIN_D0
#define LCD_RS PIN_D1
#define LCD_RW PIN_A5

//#define USE_LCD_RW   1


Note that even using the CCS driver, the problem exists.

2) CrystalFontz: CFAH1602B-TMI-JT

3) I am not using Fast or Fixed IO.

4) Single, fixed speed.

5) Config bits are as before:
Code:
#FUSES HSPLL, NOWDT, NOPROTECT, BROWNOUT, BORV20, PUT, NOCPD, NOLVP, LPT1OSC, NOMCLR, NOPBADEN, USBDIV, PLL5, CPUDIV1, VREGEN


I have tried to mimic the C18 bootloader code's configuration bits. I believe I have done so. If you want more than the fuses, let me know.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group