MOVFF opcode

[mbge5amw]

Hi,
I hope the question I have is very simple for someone, I've already spent days tracking down this peculiar bug and am at my wits end with this so please can someone help me please.

I found unexpected behaviour in my previously working CCS CAN bus routines. After much searching and comparing of listings and other output files I discovered that when I add an extra local variable to a subroutine, it has a knock on effect of altering the data layout so that a particular 32bit number (used by one of the supplied functions) crosses a bank boundary

See code below.

What I want to know is:
Is this MOVFF command valid for moving data between banks?
Does anything actually look wrong with the compiler generated opcodes?
Is my best solution going to be to reserve data for 3 bytes either side of the boundary, such that the 32 bit number won't be placed there by the linker?
Or am I just chasing wild geese with this and need to go back to the haystack to find my needle? (sorry for the metaphor overload)

Thanks in advance

Andy

[Ttelmah]

MOVFF, can talk to anywhere, in 4K of RAM space.
This covers everything, including the SFR's etc..
The 'cost' for this, is that it is a 2 cycle instruction, so for 'local' moves, it is faster to use one of the banked moves.
Look carefully at the .sym variable locations, and check them against the opcodes.

Best Wishes

[mbge5amw]

OK, ruling out the option that that was an invalid cross bank data transfer, it looks like I have now spotted the problem.

While the syntax of that command was fine, it looks like I have used all the available general purpose RAM (according to the data sheet it goes up to 0x5FF) and the compiler is now using memory from 0xD00 which is the CAN bus SFRs, which explains the big mess up occuring in my CAN bus comms.

Looks like I just need to look back through my code and see if I can free up a bit of RAM somehow, plus tell my compiler not to use the RAM above 0xD00.

Thanks for helping me rule out the incorrect syntax theory.

Andy