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 CCS Technical Support

i2c force_hw won't work

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



Joined: 11 May 2009
Posts: 22

View user's profile Send private message

i2c force_hw won't work
PostPosted: Fri Oct 08, 2010 7:18 am     Reply with quote

I've write this dummy program, to test the i2c speed.
If I set the #use i2c(... FORCE_HW) it won't work. If I delete the FORCE_HW statement, it works (about 300khz).
The source is:
Code:

#include <main.h>
#include <18F8722.h>
#use delay(clock=32000000)
#use i2c(Master,Fast=400000,sda=PIN_C4,scl=PIN_C3, force_hw)

void main()
{
   setup_oscillator(osc_32mhz);
   
   while(1)
   {
   output_bit(PIN_D3,1);
   i2c_write(0b01010101);
   output_bit(PIN_D3,0);
   }
}


the problem is here (line 00012)
Code:
00000:  GOTO   0022
.................... #use i2c(Master,Fast=400000,sda=PIN_C4,scl=PIN_C3, force_hw)
00004:  BCF    FC6.7
00006:  BCF    F9E.3
00008:  MOVFF  05,FC9
0000C:  MOVLW  02
0000E:  BTFSC  FC6.7
00010:  BRA    001C
00012:  BTFSS  F9E.3
00014:  BRA    0012
00016:  MOVLW  00
00018:  BTFSC  FC5.6
0001A:  MOVLW  01
0001C:  MOVWF  01
0001E:  GOTO   00A0 (RETURN)
.................... void main()
.................... {
00022:  CLRF   FF8
00024:  BCF    FD0.7
00026:  CLRF   FEA
00028:  CLRF   FE9
0002A:  MOVLW  70
0002C:  MOVWF  FD3
0002E:  MOVLW  40
00030:  MOVWF  F9B
00032:  MOVF   FD3,W
00034:  BSF    F94.3
00036:  BSF    F94.4
00038:  MOVLW  13
0003A:  MOVWF  FC8
0003C:  MOVLW  28
0003E:  MOVWF  FC6
00040:  BCF    FC7.7
00042:  BCF    FC7.6
00044:  MOVF   FC1,W
00046:  ANDLW  C0
00048:  IORLW  0F
0004A:  MOVWF  FC1
0004C:  MOVLW  07
0004E:  MOVWF  FB4
....................    while(1)
.................... {
.................... output_bit(PIN_D3,1);
00096:  BSF    F8C.3
00098:  BCF    F95.3
.................... i2c_write(0b01010101);
0009A:  MOVLW  55
0009C:  MOVWF  05
0009E:  BRA    0004
.................... output_bit(PIN_D3,0);
000A0:  BCF    F8C.3
000A2:  BCF    F95.3
.................... }
000A4:  BRA    0096
.................... 
.................... }
000A6:  BRA    00A6

bit F9E.3 is 0 and the BTFSS will not jump the BRA function.
I'm using PCWHD 4.104
Thanks.
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Oct 08, 2010 4:53 pm     Reply with quote

Do you have 4.7K pull-up resistors installed on the i2c bus ? You need them.
prwatCCS



Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Sat Oct 09, 2010 5:44 am     Reply with quote

Have you configured the two port pins as INPUTS? This may not be intuitive, but I seem to recall it is mentioned as a requirement in some of the POC data sheets.

Can you post the code generated by the option thta you say works?

I am currently trying to get I2C working on a PIC18F25K22 and failing - with or without FORCE_HW!
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK
blo



Joined: 11 May 2009
Posts: 22

View user's profile Send private message

PostPosted: Sat Oct 09, 2010 6:12 am     Reply with quote

I've got the pull-up resistor (2K2). I'm setting pin C3 and C4 as input
Code:
00034:  BSF    F94.3
00036:  BSF    F94.4

If I recompile with the force_sw statement it work.
Ttelmah



Joined: 11 Mar 2010
Posts: 19498

View user's profile Send private message

PostPosted: Sat Oct 09, 2010 7:31 am     Reply with quote

Start by setting up a proper I2C transaction. You cannot 'write' a byte, without first sending a start. I suspect the software is allowing this, but the hardware won't. The SSPIF, (F9E.3), only gets set, once the hardware has sent the byte. Try sending a start, the byte, then a stop. This should allow the hardware to work.

Best Wishes
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sat Oct 09, 2010 12:56 pm     Reply with quote

Quote:
If I set the #use i2c(... FORCE_HW) it won't work.

I've got the pull-up resistor (2K2). I'm setting pin C3 and C4 as input

What's the testing environment ? Is this Proteus or a real board ?
blo



Joined: 11 May 2009
Posts: 22

View user's profile Send private message

PostPosted: Sat Oct 09, 2010 6:49 pm     Reply with quote

it's a demo board from microchip (pic18explorer).
Ttelmah



Joined: 11 Mar 2010
Posts: 19498

View user's profile Send private message

PostPosted: Sun Oct 10, 2010 2:37 pm     Reply with quote

Have you actually tried sending a start first, as I suggested?.
The 'point', is that the hardware I2C, has different 'modes' of operation. It _won't_ clock out a byte, and generate the interrupt, if it is in 'idle' mode. It is in idle mode, till you send a start. Hence what you are trying to do, will cause the code to hang, as you describe.

Best Wishes
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Oct 10, 2010 3:18 pm     Reply with quote

I still say that the SCL line is either missing the pull-up or it's being held
at a Ground level. That will cause the code to lockup in the polling loop
for the SSPIF bit in PIR1, while waiting for that bit to go high.
Ttelmah



Joined: 11 Mar 2010
Posts: 19498

View user's profile Send private message

PostPosted: Mon Oct 11, 2010 1:52 am     Reply with quote

Yes. The hardware will test for this, while the software version won't. You can 'get away' with things using software approaches, which hardware won't let you do.

Best Wishes
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Mon Oct 11, 2010 1:05 pm     Reply with quote

Quote:
I still say that the SCL line is either missing the pull-up or it's being held at a Ground level.

It may be a result of missing start condition, though. If the problem persists after performing a correct I2C transaction, it's time to review the hardware.
prwatCCS



Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Tue Oct 12, 2010 8:25 am     Reply with quote

Hi

Have you got anywhere with this? As I posted earlier, I have a very similar issue with a PIC18F25K22 part (compiler version 4.112), although I have not yet tried taking out the FORCE_HW in #use i2c ( ..).

What I have is a small test routine that works if I compile for an 18F252 (at 10Mhz xtal, PLL to give 40Mhz clock), and does NOT work if I compile for the 18F25K22. It is as if there is no actual I2c clock, as I cannot even see the start bit generation, and then I hang once I've written to the SSP1BUF (at 0xFC9).

I shall start a new thread and post my findings - I am currently looking through the differences in the two list files from my good/bad compilations. Needless to say, at first glance, all the i2c stuff looks to be the same, just at slightly difference addresses.
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK
FvM



Joined: 27 Aug 2008
Posts: 2337
Location: Germany

View user's profile Send private message

PostPosted: Tue Oct 12, 2010 9:10 am     Reply with quote

Quote:
I am currently looking through the differences in the two list files from my good/bad compilations.

Which code you are referring to? In the present thread, we have yet seen only an example of incorrect I2C usage (missing start/stop), which is supposed to fail. If you have problems also with correct I2C usage, that suggests a compiler bug, please show the respective code.
prwatCCS



Joined: 10 Dec 2003
Posts: 70
Location: West Sussex, UK

View user's profile Send private message

PostPosted: Tue Oct 12, 2010 10:55 am     Reply with quote

My basic problem with the 18F25K22 part is now resolved - see the new thread I started. Turns out it related to port C pins defaulting to analog inputs and this not being set correctly by the complier when you requested I2C functionality.

I have taken a quick look at the data sheet mentioned at the beginning of this post, but sadly don't think the same applies in this instance...
_________________
Peter Willis
Development Director
Howard Eaton Lighting Ltd UK
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