View previous topic :: View next topic |
Author |
Message |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
18F4550 i2c problem (Resolved) |
Posted: Tue Oct 10, 2006 5:16 am |
|
|
Hey all,
I have an i2c chip DS4520 with the following driver:
Code: |
// ...
#use i2c(Master,Slow,sda=PIN_B0,scl=PIN_B1,force_hw)
//...
#ifndef DS4520
#define DS4520
///////////////////////////////////////////////////////////////////////////////
#define DS_write 0xA0
#define DS_read 0xA1
///////////////////////////////////////////////////////////////////////////////
void InitDS4520(void)
{
i2c_start(); //start
i2c_write(DS_write);
i2c_write(0xF0); //Word address
i2c_write(0xFF); //Enable PU
i2c_write(0xFF); // "
i2c_write(0x00); // Low
i2c_write(0x00); // "
i2c_write(0x01); // disable SEE
i2c_stop(); //stop
}
///////////////////////////////////////////////////////////////////////////////
void SetDS4520(int16 value)
{
i2c_start(); //start
i2c_write(DS_write);
i2c_write(0xF2); //Word address
i2c_write((int8)(value & 0x00FF)); // LSB
i2c_write((int8)(value >> 8)); //MSB
i2c_stop(); //stop
}
///////////////////////////////////////////////////////////////////////////////
#endif
|
This code works 100% on a PIC18Fx5x running @ 10MHz.
But when downloaded to a PIC18Fx550 running @ 20MHz (+PLL for USB) !! It's not !! It seems that the micro (the master) waits forever for ACK!!
I tried to remove the 'force_hw': it's not waiting forever anymore but the slave is not responding!!
Any idea? I mean it should work (same code, same 18F arch.)
Thank you in advance.
Last edited by PICoHolic on Thu Oct 12, 2006 3:12 am; edited 2 times in total |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Oct 10, 2006 11:54 am |
|
|
Post the exact PICs that you're using. Post your compiler version.
If possible, post a short, but complete demo program that shows
the problem. |
|
![](templates/subSilver/images/spacer.gif) |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
|
Posted: Wed Oct 11, 2006 12:22 am |
|
|
Basically there is no code, just calls:
(DS4520 is an i2c port expander)
- The PIC18F4550 stalls on the first call!
- Compiler v: 3.234 & 4.008 (same problem)
Code: |
InitDS4520();
delay_ms(1);
SetDS4520(0xAAAA);
|
Plus of course: (for the PIC18F4550)
Code: |
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,USBDIV,PLL5,CPUDIV1,VREGEN
#use delay(clock=48000000)
#use i2c(Master,Slow,sda=PIN_B0,scl=PIN_B1,force_hw)
|
For the PIC18F452:
Code: |
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES HS //High speed Osc (> 4mhz)
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOOSCSEN //Oscillator switching is disabled, main oscillator is source
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES PUT //Power Up Timer
#FUSES NOSTVREN //Stack full/underflow will not cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOCPD //No EE protection
#FUSES NOCPB //No Boot Block code protection
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#use delay(clock=10000000)
#use i2c(Master,Slow,sda=PIN_C4,scl=PIN_C3,force_hw)
|
Is that enough?
Thank you PCM programmer! |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Wed Oct 11, 2006 12:29 am |
|
|
These PICs are not pin compatible therefore I conclude it is not the same hardware platform. Have you checked for hardware bugs?. Are the pull ups installed, have the clock and data lines be transposed. Do the traces actually go between the chips.... _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
|
Posted: Wed Oct 11, 2006 12:51 am |
|
|
hey asmallri
Everything is double-checked!
I'm using 2 different eval board.
And also i'm using the same connector! (different pins) to have everything look like same!
10x |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Oct 11, 2006 2:24 pm |
|
|
I can confirm that hardware i2c doesn't work with your setup.
I just don't know why yet. I don't have any more time to work on it
this afternoon. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Wed Oct 11, 2006 2:59 pm |
|
|
I have seen a problem some time ago, which at the time I did not believe, but a lot of fiddling by another programmer proved that it was happening.
The behaviour was that on some PICs, with some slave devices, the SSPIF flag does not get internally set for the ACK, which the code waits for, resulting in the system hanging. The behaviour was improved, by massively reducing the I2C pull up resistors (beyond the specified limits), but still not totally fixed. It only applied to certain PICs, with tests done using an 'old' 16F876, working fine, but the same code in a latter 18F chip displaying the problem. Changing the I2C speed, did not affect the behaviour. In his case, is was a 'repeated start', that caused the problem, and manually issuing a 'stop/start' sequence fixed it.
Software I2C, ran fine.
I would try the following steps:
1) Specify the clock rate. The I2C instruction, now accepts a required rate along with the slow/fast keywords, and you might as well start with a known slow rate.
2) What happens if you use software I2C?.
3) Have you checked for any I2C erratas on your chip (there are a _lot_ on some 18F devices...).
4) Try reducing the pull-ups.
5) Note the 0.6uSec setup time required between the last write, and the stop bit. At 20MHz, you may need to explicitly add a delay.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Oct 11, 2006 5:46 pm |
|
|
I tried software i2c on those pins, with a very simple program (not using
the PLL), and it worked OK. I saw waveforms on the oscilloscope. This
is with PCH vs. 3.249.
I added FORCE_HW to the #use i2c() statement, keeping everything
else the same, and it didn't work. I think the .LST file looks OK.
I didn't check it 100%, but maybe 90%.
There is an errata which says the hardware i2c module may not
start-up correctly from power-on reset. It suggests a work-around.
The problem is that we can't disable the CCS start-up code.
So the work-around code has to be placed after the start-up code.
I tried that. It didn't fix the problem.
There could still be a problem in CCS's implementation of hardware i2c.
There may be something in the .LST file that I missed. I just don't
want to commit any more time on this, at least for now. As a work-
around, I suggest using software i2c. |
|
![](templates/subSilver/images/spacer.gif) |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
|
Posted: Thu Oct 12, 2006 12:17 am |
|
|
Thank you PCM programmer & Ttelmah
I have tried the software i2c on 18F4550 and it didnt work! But it worked on the PIC18F452 (both SW & HW).
Regarding erratas, i've found one for the MSSP in SPI mode (18F4550) and not I2C.
Plz take a look on:
-Scope shot for the 18F452 (SW)
-Scope shot for the 18F4550 (SW)
FOR THE SAME CODE
(Ch1: SDA, Ch2: CSL)
Any comment!? ![Wink](images/smiles/icon_wink.gif) |
|
![](templates/subSilver/images/spacer.gif) |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
18F4550 i2c problem (Resolved) |
Posted: Thu Oct 12, 2006 3:11 am |
|
|
Finally ....
It's working now!
Guess what, i had to change the SDA & SCL pins from (RB0, RB1) to (RC0, RC1) for the SW I2C. I dont have an explanation! (SPI & ADC are disabled)
Thank you!
Last edited by PICoHolic on Thu Oct 12, 2006 3:57 am; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu Oct 12, 2006 3:29 am |
|
|
Indeed, strange but as you didn't post a complete demo program all we can do is guessing. It might have been something to do with the analog inputs on RB0 and RB1 that are enabled by default. Or maybe somewhere in your program you are enabling the external interrupt on RB0, without handler code this would explain your processor stalling, etc., etc.
Again, to me this indicates the importance of a complete demo program, not just snapshots. |
|
![](templates/subSilver/images/spacer.gif) |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
|
Posted: Thu Oct 12, 2006 4:00 am |
|
|
As I mentioned SPI & ADC are disabled, no interrupts enabled too...
Thanks anyway |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Thu Oct 12, 2006 4:27 am |
|
|
You say the analog port is disabled. How?. Have you got the NOPBADEN fuse?. If not the port wll default to analog.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
PICoHolic
Joined: 04 Jan 2005 Posts: 224
|
|
Posted: Thu Oct 12, 2006 4:34 am |
|
|
Yes i've added it later without updating the posted fuses.
Sorry Ttelmah
Thanks |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah Guest
|
|
Posted: Thu Oct 12, 2006 6:57 am |
|
|
I would be adding:
setup_adc(NO_ANALOGS);
and a clock rate definition to the use I2C (there was a problem with the new 'variable' speeds were introduced that the 'old' syntax, did not allways behave 'right').
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
|