View previous topic :: View next topic |
Author |
Message |
blo
Joined: 11 May 2009 Posts: 22
|
i2c force_hw won't work |
Posted: Fri Oct 08, 2010 7:18 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Fri Oct 08, 2010 4:53 pm |
|
|
Do you have 4.7K pull-up resistors installed on the i2c bus ? You need them. |
|
![](templates/subSilver/images/spacer.gif) |
prwatCCS
Joined: 10 Dec 2003 Posts: 67 Location: West Sussex, UK
|
|
Posted: Sat Oct 09, 2010 5:44 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
blo
Joined: 11 May 2009 Posts: 22
|
|
Posted: Sat Oct 09, 2010 6:12 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19382
|
|
Posted: Sat Oct 09, 2010 7:31 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sat Oct 09, 2010 12:56 pm |
|
|
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 ? |
|
![](templates/subSilver/images/spacer.gif) |
blo
Joined: 11 May 2009 Posts: 22
|
|
Posted: Sat Oct 09, 2010 6:49 pm |
|
|
it's a demo board from microchip (pic18explorer). |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19382
|
|
Posted: Sun Oct 10, 2010 2:37 pm |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun Oct 10, 2010 3:18 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19382
|
|
Posted: Mon Oct 11, 2010 1:52 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Mon Oct 11, 2010 1:05 pm |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
prwatCCS
Joined: 10 Dec 2003 Posts: 67 Location: West Sussex, UK
|
|
Posted: Tue Oct 12, 2010 8:25 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Tue Oct 12, 2010 9:10 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
prwatCCS
Joined: 10 Dec 2003 Posts: 67 Location: West Sussex, UK
|
|
Posted: Tue Oct 12, 2010 10:55 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
|