Migrating from 18F252 to 18F2520

[dinder]

Since Microchip recommends using the 2520, and it allows usings its internal RC osc, saving an external Xtal, seemed the right thing to do.
After a quick comparison of datasheets, I 'only' changed the #fuse settings and set up the internal oscillator as well as changing over to include the 18F2520.
However my program now is unstable, it powers up OK, and then appears to Reset, or jump to random locations. I've looked at obvious Reset causes, but the Watch Dog timer is unused, and I didn't use the Stack over/under flow, although enabled.
Looks like the memory access is flawed, as I have 3 serial coms (1 uses hardware UART that is sw polled, and 2 sw (assembly code) uses RB0, 1 interrupts for rx, and timers int, all in background)
I have an executive loop, where I check for comm data (none occuring as I have nothing connected, and checked data line clean with scope)
One instance that indicates the ram access is flawed is the following line,
while (Rx_TailL != Rx_HeadL)
I have the debug set on the next line, BUT Rx_TailL and Rx_HeadL are both Zero (and should be as far as I am concerned as no serial traffic), so I am confused as to why the debugger fired, as the 'while' condition should never have been met. Looks like the incorrect memory addressing, it would explain the odd programme behaviour, but I am unclear why the change to over to the 2520 creates this problem.
Any one had similar problems?

Original 252 code lines I changed
*.h file

#include <18F252.h>
// #device ICD=TRUE
#device adc=8

enum {PC_Printer,Balance,BarCode};

#use delay(clock=4000000)
#fuses NOWDT, XT, NOPROTECT, NOOSCSEN, BROWNOUT, BORV20, PUT, STVREN, NODEBUG, NOLVP, NOWRT, NOWRTD, NOWRTB, NOWRTC, NOCPD, NOCPB, NOEBTR, NOEBTRB

and start of main loop:
void main()
{
int i = 0;

disable_interrupts(global);

//; initialise SW UART control registers for console and Balance ports


'ONLY' changes to previously working programme, for 2520
*.h file;
#include <18F2520.h>
// #device ICD=TRUE
#device adc=8

enum {PC_Printer,Balance,BarCode};

#use delay(clock=4000000)
#fuses NOWDT,INTRC_IO,NOPROTECT,NOBROWNOUT,PUT,STVREN,DEBUG,NOLVP,NOFCMEN,NOXINST

and in main loop;
void main()
{
int i = 0;

disable_interrupts(global);

setup_oscillator(OSC_4MHZ|OSC_INTRC);

//; initialise SW UART control registers for console and Balance ports

[rwyoung]

There is an extensive errata sheet for the 18f2520 on Microchip.com. You should check it for anything that might be affecting your code.

Also, one thing I see is that while you have the #device ICD=TRUE commented out, you still have the DEBUG fuse active.

I have had some issues with the power up timer and brownout detectors on chips, you might want to look into their operation.

You can also ask the PIC its reason for reset. If your serial ports work OK right after reset, consider using one as a monitor port and sending out some status messages.
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[dinder]

I did exactly that, the hw serial port is the only one connected, and the program originally outputs a header and default parameters after power up. This all works correctly, after every power off/on cycle or Reset from debugger.
Using restart_cause(), I always get 12 (normal start) at power up or debuuger reset.
The program should then wait for an event to occur (in this case a button press on RB4), while flashing a couple of LED's, and no event should occur, as I have not connected any of the hardware, apart from the pc serial cable. However, after a few moments, the program has 'crashed' and I get re-sending of serial data, or other incorrect stuff.

I'll read the errata sheet, in the meantime I have located a previous pcb with F252, and that is working ok, so was going to compare hex files

[dinder]

Thanks Rob, reading the errata sheet, appears to indicate where the problem may be.
There is an interrupt issue, If an interrupt occurs during a two-cycle instruction that modifies the STATUS, BSR or WREG register, the unmodified value of the register will be saved to the corresponding Fast Return (Shadow) register and upon a fast return from the interrupt, the unmodified value will be restored to the STATUS, BSR or WREG register.

I was sure the BSR was getting corrupt, now have to implement the work-around. In fact I think I now recall seeing this work-around in some C18 C code.