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

MOVFF opcode

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



Joined: 13 Dec 2004
Posts: 15
Location: Yorkshire, UK

View user's profile Send private message MSN Messenger

MOVFF opcode
PostPosted: Mon Mar 29, 2010 8:05 am     Reply with quote

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


Code:

....................    //set tx mask
....................    can_set_id(TXRXBaID, id, ext);
21F6:  MOVLW  0F
21F8:  MOVWF  xFC
21FA:  MOVLW  64
21FC:  MOVWF  xFB
21FE:  MOVFF  5EC,D03
2202:  MOVFF  5EB,D02
2206:  MOVFF  5EA,D01
220A:  MOVFF  5E9,D00
220E:  MOVFF  5F1,5FD
2212:  MOVLB  0
2214:  RCALL  2044



and here is the relevant hex file data
Code:


2206:  MOVFF  5EA,D01
EA C5 01 FD

220A:  MOVFF  5E9,D00
E9 C5 00 FD

220E:  MOVFF  5F1,5FD
F1 C5 FD F5





Device PIC18F2580
CCS PCH C Compiler, Version 3.236
problem variable: id in can_putd()
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Mar 29, 2010 9:54 am     Reply with quote

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



Joined: 13 Dec 2004
Posts: 15
Location: Yorkshire, UK

View user's profile Send private message MSN Messenger

PostPosted: Tue Mar 30, 2010 4:15 am     Reply with quote

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
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