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

PIC18F4585 halts at the same spot every time

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
iso9001



Joined: 02 Dec 2003
Posts: 262

View user's profile Send private message

PIC18F4585 halts at the same spot every time
PostPosted: Tue Jul 22, 2008 6:09 pm     Reply with quote

Hi,

I recently made a bunch of pcbs that use the 4585 chip. They were based with very few hardware changes on a prototype design that used 4480 and 4680 chips. I needed more room so I upgraded chips, but I have a feeling there is something very wrong with the .h file or ccs's builtins when using the 4585.

The problem is the code runs to a specific line then quits. It seems the chip craps out around when timer1 overflows. The stack window in ICD reports (on the error) that "Code 0x?? is outside of any functions"

Sometimes a window pops up saying "TByteStack Empty", but I can't find info on that.

Here are the fuses: (10mhz xtal with pll)
Code:

#fuses H4,NOLVP,NOWDT,PUT,NOBROWNOUT,
#use delay(clock=40000000)


And here is the interrupt page of the ICD.... There is something very odd around GIE:
Code:

INTCON     FF2   00010001   0x11 
INTCON2    FF1   1111X1X1   0xF5 
INTCON3    FF0   11X00X00   0xC0 
RCON       FD0   00X11100   0x1C 
PIR1       F9E   00000000   0x00 
PIE1       F9D   00000001   0x01 
IPR1       F9F   11111111   0xFF 
PIR2       FA1   00000000   0x00 
PIE2       FA0   00000000   0x00 
IPR2       FA2   11011111   0xDF 
PIR3       FA4   00000000   0x00 
PIE3       FA3   00000000   0x00 
IPR3       FA5   11111111   0xFF 


ADIF       F9E.6           0    The A/D conversion is not complete
RCIF       F9E.5           0    The USART receive buffer is empty
TXIF       F9E.4           0    The USART transmit buffer is full
CCP1IF     F9E.2           0    No TMR1 register capture occurred
TMR2IF     F9E.1           0    No TMR2 to PR2 match occurred
TMR1IF     F9E.0           0    TMR1 register did not overflow
OSCFIF                     0    System clock operating
EEIF                       0    The write operation is not complete or has not been started
BCLIF                      0    No bus collision has occurred
LVDIF                      0    The device voltage is above the Low Voltage Detect trip point
TMR3IF                     0    TMR3 register did not overflow
CCP2IF                     0    No TMR1 register capture occurred
GIE/GIEH   FD0.7--15925506 0    All interrupts disabled
PEIE/GIEL                  0    All low priority peripheral interrupts disabled
TMR0IE     FF2.5           0    TMR0 overflow interrupt disabled
INT0IE     FF2.4           1    INT0 external interrupt enabled
RBIE       FF2.3           0    RB port change interrupt disabled
TMR0IF     FF2.2           0    TMR0 register did not overflow
INTF       FF2.1           0    The INT0 external interrupt did not occur
RBIF       FF2.0           1    At least one of the RB7:RB4 pins changed state (must be cleared in software)
RBPU       FF1.7           1    All PORTB pull-ups are disabled
INTEDG0    FF1.6           1    Interrupt on rising edge
INTEDG1                    0    RB Port Change Interrupt Priority bit: Low  priority
INT2IP     FF0.7           1    INT2 External Interrupt Priority bit: High priority
INT1IP     FF0.6           1    INT1 External Interrupt Priority bit: High priority
INT2IE     FF0.4           0    INT2 external interrupt disabled
INT1IE     FF0.3           0    INT1 external interrupt is disabled
INT2IF                     0    The INT1 external interrupt did not occur



Here is some code snippets:
Code:

 initModule();  //Sets up default pin states

//init SPI for EEPROM or Add-on
setup_spi(SPI_MASTER | SPI_H_TO_L | SPI_XMIT_L_TO_H | SPI_CLK_DIV_4);
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8);   //needed for wake timeout (56ms)

 //init iCAN Module
 output_low(SLOPE_VEH); //enable can transceiver
 CANConfig();
 delay_us(5);

 //init ints
 enable_interrupts(INT_TIMER1); // turn on interrupts
 enable_interrupts(GLOBAL);
 set_timer1(0);

 //init program data
 can_timeout=0;


 while(1) {

... main program code, quits somewhere in here depending on what I'm debugging



Thing is, it ALL works fine with the 4480 part in the old pcb. I think I'm going to have to desolder one of these chips and see if it could be something on the board, or if its this 4585 part.

Can anyone help point me in the right direction ?
Thanks!
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jul 22, 2008 7:24 pm     Reply with quote

Quote:
The problem is the code runs to a specific line then quits.

1. What happens if you run the program in stand-alone mode ?
I.e., not using the ICD debugger. Does it lock up ? What are the
symptoms ?

2. You have a comma at the end of your #fuses statement.
Is that a complete listing of the fuses used in your real program ?

3. What is your compiler version ?
iso9001



Joined: 02 Dec 2003
Posts: 262

View user's profile Send private message

PostPosted: Tue Jul 22, 2008 8:11 pm     Reply with quote

The comma was my fault. I had tried the program with the 'stack overflow no reset' fuse and then without. To avoid questions I removed it from the post but forgot to remove the comma.

Compiler is the last version before 4.0, So, 3.249 I think

Yes, it happen with or without the debugger connected.



I'm worried, I can't think of a single thing that would be different between this and the 4680 (except memory of course).

I think I'll look into....... crap, I really have no ideas.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jul 22, 2008 8:46 pm     Reply with quote

If you think the code is different, then print the .LST files for both of
the PICs and compare the results, line by line.

Ideally, try to create a short program that still has the same failure mode.
Then there is a lot less code to compare.
iso9001



Joined: 02 Dec 2003
Posts: 262

View user's profile Send private message

PostPosted: Tue Jul 22, 2008 10:45 pm     Reply with quote

I'll check the list,

The thing is, I expect the .lst to be exactly the same. What I think the problem would be is differences in the chips (maybe?).

I'll try a scaled back representation of the code (that I can post here) and see if I can sandbox the problem, but I think its something related to my code's ram and rom footprint along with something about CCS's interrupts methods.

I think I can confirm that it hangs when timer1 rolls over, but I can't figure out why it works on my other pcbs with the 4480.... I'll have to check what is hooked to timer1 pins and other external interrupt hardware.

Almost all pins are left at their default states on reboot but I'll double check for something odd.

Also, the reboot_cause() always reports 'normal powerup'

I'm getting a little concerned :(
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Tue Jul 22, 2008 11:13 pm     Reply with quote

Quote:

The thing is, I expect the .lst to be exactly the same. What I think the problem would be is differences in the chips (maybe?).

But in your previous post you said you suspected that the CCS generated
code is different for the new PIC:
Quote:

But I have a feeling there is something very wrong with the .h file or
ccs's builtins when using the 4585.


That's why I suggested that you compare the .LST files. That will confirm
whether your suspicions are correct or not.
iso9001



Joined: 02 Dec 2003
Posts: 262

View user's profile Send private message

PostPosted: Wed Jul 23, 2008 3:41 pm     Reply with quote

Hmmmm.... Well, I checked the list. There are a couple of differences but nothing crazy. The most noticable is that the most of the branch and goto locations are different, since the two parts have different sized memories I'll ignore this.

I can't explain this one, but since its only the omission of a single nop, I won't sweat it.
Code:

4585
1008:  MOVWF  FE9
100A:  DECFSZ FE9,F
100C:  BRA    100A
100E:  NOP
1010:  NOP
1012:  BTFSC  01.7
1014:  BRA    0FD6

4480
1008:  MOVWF  FE9
100A:  DECFSZ FE9,F
100C:  BRA    100A
100E:  NOP
1010:  NOP
1012:  NOP
1014:  BTFSC  01.7


This puzzled me for about 10 minutes. I couldn't figure out why the 4585 part had mysterious writes to 0xFFA. That register belongs to EEPROM address's 2 MSBs, since the 4480 part has only 256bytes of ee it doesn't need to use those bits. So, mystery solved there.
Code:

4585
1CA2:  ADDWFC 03,W
1CA4:  MOVWF  FEA
1CA6:  MOVFF  FEF,147
1CAA:  MOVFF  146,FAA
1CAE:  MOVFF  145,FA9
1CB2:  MOVFF  147,FA8
1CB6:  BCF    FA6.6
1CB8:  BCF    FA6.7
1CBA:  BSF    FA6.2
1CBC:  MOVFF  FF2,00

4480
1CA2:  ADDWFC 03,W
1CA4:  MOVWF  FEA
1CA6:  MOVFF  FEF,147
1CAA:  MOVFF  145,FA9
1CAE:  MOVFF  147,FA8
1CB2:  BCF    FA6.6
1CB4:  BCF    FA6.7
1CB6:  BSF    FA6.2
1CB8:  MOVFF  FF2,00



No real change in the asm. I took another crack at it with the interrupt turned on but no isr routine for it. This didn't work yesterday but does today (@$&#!!!!!) so... I guess I'll go back to turning on segments of code until it breaks again, however, I have a feeling that I will never find out what the problem was.... I'll blame it on solar flares I guess.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
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