Problem: 18LF242 keeps resetting (POR)

[Michi]

Having recently upgraded from using PCH 3.100 (within PCWH IDE) to PCH 3.150 (within MPLAB 6.13) I am getting a weird problem (with a 18LF242).

The code below resets the PIC about once per second and does not reach the following line:

printf("Hello "); in function init_all()

When I remove the ISR...

#int_RB
RS232_interrupt()

..it all works fine. As you can see, no interrupts are enabled.

The watchdog is disabled and I have tested the restart_cause() value and this points to a normal POR (0x0C).

Any help pointing me in the right direction is greatly appreciated. Thanks.

------

The code attached below has been cut down from about 90\% ROM usage to the following while still showing the problem explained above:


#include <18F242.H>
#device *=16

#fuses HS,PROTECT,NOOSCSEN,NOBROWNOUT,NOWDT,WDT128,PUT,CCP2C1,STVREN,NODEBUG,NOLVP,NOWRT,WRTD,NOWRTB

#use delay(clock=3686400)
#use rs232(baud=4800, xmit=PIN_C6, rcv=PIN_C7, parity=N, bits=8, errors)
#use fast_io(A)
#use fast_io(B)
#use fast_io(C)

#PRIORITY ext, rb

// map registers:

#bit POR = 0xFD0.1
#bit BOR = 0xFD0.0
#bit RI = 0xFD0.4
#byte port_b = 0xF81
#bit RBIF = 0xFF2.0

// global variables:

int last_b;
short CTS_RTS;
short CTS_high=false;
short char_received=false; // flag: incoming data over RS-232

// FUNCTION PROTOTYPES:

void activate_LED(short state);
void init_all(void);

// - M A I N -
// ------------------------------------------------------------

main()
{

printf("RESET: \%X ",restart_cause());
bor=1;
ri=1;

switch ( restart_cause() )
{
case NORMAL_POWER_UP:

init_all();
por=1;
}

while(1) // loop forever...
{}

}

// ----------------------------------------------------------

void init_all(void)
{
set_tris_A(0b00011001);
set_tris_B(0b00101111);
set_tris_C(0b10011001);

output_high(PIN_C5); // LED on
delay_ms(150);
output_low(PIN_C5); // LED off
delay_ms(255);

activate_LED(1);

printf("Hello ");

// last_b=port_b; // read port_B to reset RBIF (undefined after POR)
// RBIF=0; // clear RBIF flag
// char_received=false;

// enable_interrupts(INT_RB);
// disable_interrupts(GLOBAL);
}

// ------------------------------------------------------------

void activate_LED(short state)

{
switch (state)
{
case 1:
output_high(PIN_C5); // LED on
break;

case 0:
output_low(PIN_C5); // LED off
break;
}
}

//----------------------------------------------------------

#int_RB

RS232_interrupt() // interrupt on PIN change
{

// RB4..7 can cause an RB interrupt:
// RB4 is output hence cannot cause an interrupt in this application
// RB5 is defined as input (parallel to RXD)
// RB6 is I/O-4 (defined normally as output)
// RB7 is I/O-3 (defined normally as output)


int changes;
short int found_int;

changes=last_b ^ port_b;
last_b=port_b;

found_int=false;

if (bit_test(changes,6))
{
found_int=true;
if (bit_test(last_b,6)) // RB6 = I/O-4 = CTS changed from low to high
{
if (CTS_RTS==1) // if handshaking enabled
{
CTS_high=true;
}
}
}

if (!found_int) // if no interrupt found assume it is...
{ // ...RS232 data arriving
char_received=true; // (fast changing state of RB5 makes it difficult to detect)
}

activate_LED(1); // Status LED on
}
___________________________
This message was ported from CCS's old forum
Original Post ID: 13578

[Michi]

I have narrowed it down to some odd code being produced when the switch (state){} is used.
The code further below without the switch statement works fine.

Any ideas?

======================================
THIS RESETS EVERY SECOND OR SO:
======================================

.................... activate_LED(int state)
.................... {
.................... // output_high(PIN_C5); // LED on
....................
....................
.................... switch (state)
*
00CE: MOVF 1D,W
00D0: ADDLW FE
00D2: BTFSC FD8.0
00D4: GOTO 00EA
00D8: ADDLW 02
00DA: GOTO 00EC
.................... {
.................... case 1:
.................... output_high(PIN_C5); // LED on
00DE: BSF F8B.5
.................... break;
00E0: GOTO 00EA
....................
.................... case 0:
.................... output_low(PIN_C5); // LED off
00E4: BCF F8B.5
.................... break;
00E6: GOTO 00EA
.................... }
00EA: RETLW 00
00EC: BTFSS 0D.7
00EE: GOTO 00F8
00F2: MOVFF FF2,0E
00F6: BCF FF2.7
00F8: ADDWF FE8,W
00FA: ADDLW 19
00FC: MOVWF FF6
00FE: MOVLW 01
0100: MOVWF FF7
0102: BTFSC FD8.0
0104: INCF FF7,F
0106: TBLRD*-
0108: MOVF FF5,W
010A: MOVWF FFA
010C: TBLRD*
010E: MOVF FF5,W
0110: BTFSS 0D.7
0112: GOTO 011A
0116: BTFSC 0E.7
0118: BSF FF2.7
011A: MOVWF FF9
011C: DATA E4,00
011E: DATA DE,00
....................
....................
.................... }
....................
.................... // -------------------------------------------------------------------------------------------------------
.................... // - M A I N -
.................... // -------------------------------------------------------------------------------------------------------
....................
.................... main()
.................... {
*
0208: CLRF FF8


======================================
THIS WORKS:
======================================

This is what it looks like when the switch (state) {} part is commented out.


.................... activate_LED(int state)
.................... {
.................... // output_high(PIN_C5); // LED on
....................
.................... output_high(PIN_C5); // LED on
*
0004: BSF F8B.5
0006: RETLW 00
....................
.................... /*
.................... switch (state)
.................... {
.................... case 1:
.................... output_high(PIN_C5); // LED on
.................... break;
....................
.................... case 0:
.................... output_low(PIN_C5); // LED off
.................... break;
.................... }
....................
.................... */
.................... }
....................
.................... // -------------------------------------------------------------------------------------------------------
.................... // - M A I N -
.................... // -------------------------------------------------------------------------------------------------------
....................
.................... main()
.................... {
*
01B6: CLRF FF8
___________________________
This message was ported from CCS's old forum
Original Post ID: 13585

[PCM programmer]

:=I have narrowed it down to some odd code being produced when the switch (state){} is used.
:=
------------------------------------------------------------

I don't have PCH so I can't help too much, but CCS does
have problems with switch statements sometimes.
From the versions page:

3.066 A optimization bug with switch..case 0 in some programs is fixed

3.143 A bug was fixed that occured with nested switches across a 64K boundry


As work-around, I suggest using if-else statements.
___________________________
This message was ported from CCS's old forum
Original Post ID: 13588

[Michi]

:=:=I have narrowed it down to some odd code being produced when the switch (state){} is used.
:=:=
:=------------------------------------------------------------
:=
:=I don't have PCH so I can't help too much, but CCS does
:=have problems with switch statements sometimes.
:=From the versions page:
:=
:=3.066 A optimization bug with switch..case 0 in some programs is fixed
:=
:=3.143 A bug was fixed that occured with nested switches across a 64K boundry
:=
:=
:=As work-around, I suggest using if-else statements.

Thanks for your reply.

That seems to work - unfortunately I wasted 2 days of gradually narrowing down the fault.

I'll let CCS know about it...

___________________________
This message was ported from CCS's old forum
Original Post ID: 13590

[R.J.Hamlett]

:=:=:=I have narrowed it down to some odd code being produced when the switch (state){} is used.
:=:=:=
:=:=------------------------------------------------------------
:=:=
:=:=I don't have PCH so I can't help too much, but CCS does
:=:=have problems with switch statements sometimes.
:=:=From the versions page:
:=:=
:=:=3.066 A optimization bug with switch..case 0 in some programs is fixed
:=:=
:=:=3.143 A bug was fixed that occured with nested switches across a 64K boundry
:=:=
:=:=
:=:=As work-around, I suggest using if-else statements.
:=
:=Thanks for your reply.
:=
:=That seems to work - unfortunately I wasted 2 days of gradually narrowing down the fault.
:=
:=I'll let CCS know about it...
:=
Add a 'default' statement to your switches.
The compiler switches the way it generates the code if this is present.

Best Wishes
___________________________
This message was ported from CCS's old forum
Original Post ID: 13594