|
|
View previous topic :: View next topic |
Author |
Message |
Cappiam
Joined: 10 Apr 2018 Posts: 17 Location: New England
|
I2C help: PIC18F4580, Hardware I2C Locks on Write |
Posted: Tue Apr 10, 2018 10:54 am |
|
|
I am fairly new to Pic C. I've used C30 and C18, and PicBasic in the past. But this is the compiler used at my new job. That said, I'm trying to use hardware I2C with the built in functions. To initialize I2C, I'm using
Code: |
#fuses HS, WDT16384
#use delay(clock=40M, restart_wdt)
#use i2c(MASTER, SLOW, sda=PIN_C4, scl=PIN_C3) |
However, I have tried most combinations of SLOW/FAST, I2C1/SDA= SDI=, NOFLOAT_HIGH, FORCE_HW.
In all cases, the firmware freezes at the first instance of i2c_write(). If I pause the code in debug, it is sitting at the #use I2C line.
I've included the current location where it locks from my main code. I've tried test code as well and it always sits and waits at i2c_write(). This code works fine if I FORCE_SW.
Code: | void configureGPIOPort(unsigned int8 deviceAdd, unsigned int8 devicePort, unsigned int8 *registers, unsigned int8 *settings, unsigned int8 length)
{
int8 i;
i2c_start();
//__________________________________
//*****Locks on this command
i2c_write(deviceAdd);
//__________________________________
i2c_write(0x18);
i2c_write(devicePort);
//i2c_stop();
for (i = 0; i < length; i++)
{
restart_wdt();
i2c_start();
i2c_write(deviceAdd);
i2c_write(registers[i]);
i2c_write(settings[i]);
i2c_stop();
}
} |
So if anyone has a suggestion why the hardware I2C freezes the firmware, or can at least tell me how to directly work with the registers I'd appreciate it. At this point in if I was coding in C30, I would write the code for I2C using the hardware registers in the PIC, and test that but I'm not familiar enough with PIC C to know how to manipulate registers directly.
For reference, the PIC is running on 3.3V, and has a 1.5K pull-up on each I2C line. Approximately 3 to 5 inches of trace length between the PIC and I2C slave chips, of which there are two on the bus. I have tried lowering the pull up resistor to 725 ohms without any change. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Apr 10, 2018 11:29 am |
|
|
1. What numeric value are you using for deviceAdd ?
2. What is your CCS compiler version ?
3. What is your crystal frequency ? Are you using a crystal ?
4. What is the full part number (F vs. LF) of your PIC, including the
temperature grade ? |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9245 Location: Greensville,Ontario
|
|
Posted: Tue Apr 10, 2018 11:42 am |
|
|
just a couple of things....
I'd run PCM P's 'I2C Scanner' program, from the code library BEFORE coding/running your program. It'll at least confirm seeing the slaves.
Also I'd get rid of the WDT code. Normally, you don't add it until 100% of the code is working. |
|
|
Cappiam
Joined: 10 Apr 2018 Posts: 17 Location: New England
|
|
Posted: Tue Apr 10, 2018 12:09 pm |
|
|
PCM programmer wrote: | 1. What numeric value are you using for deviceAdd ? |
That is the address of the I2C chip, in this case it is either 64, or 66, if we count the 0 added for the write bit, 32 or 33 otherwise. (IE I'm sending 64 or 66 depending on the device I'm accessing, but the "address" is actually #32 or 33)
Keep in mind, if I use FORCE_SW, all of the code works correctly. It communicates correctly with the I2C slave chips, barring about a 0.5% glitch rate, which is why I'd like to try the hardware I2C.
PCM programmer wrote: | 2. What is your CCS compiler version ? |
5.075
PCM programmer wrote: | 3. What is your crystal frequency ? Are you using a crystal ? |
40mhz crystal. As far as I can tell, this runs correctly based on other testing I did on the circuit, and the RS232 interface with the zigbee wireless chip.
PCM programmer wrote: | 4. What is the full part number (F vs. LF) of your PIC, including the
temperature grade ? |
PIC18F4580-I/PT
temtronic wrote: | I'd run PCM P's 'I2C Scanner' program, from the code library BEFORE coding/running your program. It'll at least confirm seeing the slaves.
Also I'd get rid of the WDT code. Normally, you don't add it until 100% of the code is working. |
I am not familiar with PCM Ps 'I2C scanner' so where would I find that,? However, I do know the devices are accessible via the software I2C.
As for the WDT, I can eliminate it, but it doesn't affect the results of the I2C line(I've already tried with it disabled), and the firmware is complete other than the lack of hardware I2C. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Apr 10, 2018 12:38 pm |
|
|
Cappiam wrote: |
PIC18F4580-I/PT
The PIC is running on 3.3V
|
According to the 18F4580 data sheet, your PIC part number will only run
properly at 4.2v or higher. Look at this graph on page 422:
Quote: |
FIGURE 28-1: PIC18F2480/2580/4480/4580 VOLTAGE-FREQUENCY GRAPH
(INDUSTRIAL, EXTENDED) |
Data sheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/39637d.pdf
Cappiam wrote: | 40mhz crystal
|
Look at Param. 1A, in the lower section for "Oscillator Frequency".
It shows that for the HS fuse, a crystal frequency range of 4 to 25 MHz
is supported.
Quote: | TABLE 28-6: EXTERNAL CLOCK TIMING REQUIREMENTS |
Your basic problem is that you're running the PIC way out of spec.
It's my suspicion that this is the reason why hardware i2c doesn't work. |
|
|
Cappiam
Joined: 10 Apr 2018 Posts: 17 Location: New England
|
|
Posted: Tue Apr 10, 2018 2:38 pm |
|
|
Quote: | According to the 18F4580 data sheet, your PIC part number will only run
properly at 4.2v or higher. Look at this graph on page 422:
Look at Param. 1A, in the lower section for "Oscillator Frequency".
It shows that for the HS fuse, a crystal frequency range of 4 to 25 MHz
is supported.
TABLE 28-6: EXTERNAL CLOCK TIMING REQUIREMENTS
Your basic problem is that you're running the PIC way out of spec.
|
Yep, you're right. I didn't catch that when I was reviewing the design. It's a easy fix to switch out the crystal for a 20MHz one. Thanks for spotting that. I'll get the new crystal in and try the hardware I2C again.
The basic MCU part of the design was done when I was hired, and I should have checked it more carefully. I've had a lot of these minor issues because of it. |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9245 Location: Greensville,Ontario
|
|
Posted: Tue Apr 10, 2018 4:38 pm |
|
|
yeah... someone else's 'minor issues' ALWAYS become major problems, especially for the next guy !...
Overclocking a PIC a LITTLE can be done, but 40MHz out of a 25MHz device is a wee bit too much. Usually heat kills them after a day or two, for sure a long weekend !
One problem is being familiar with one series of PICs, then being tossed a 'new' one.....as you found out the 'rules' don't apply for all PICs.
Too many PICs, too little time... |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue Apr 10, 2018 5:49 pm |
|
|
Cappiam wrote: | Yep, you're right. I didn't catch that when I was reviewing the design. It's a easy fix to switch out the crystal for a 20MHz one. Thanks for spotting that. I'll get the new crystal in and try the hardware I2C again.
The basic MCU part of the design was done when I was hired, and I should have checked it more carefully. I've had a lot of these minor issues because of it. |
You didn't address all the issues that I brought up. You're still using
the "F" version of the 18F4580. You're still running it at 3.3v.
That's not allowed, per the data sheet. The minimum Vdd for the "F"
version is 4.2v.
Suppose you buy the "LF" version. The frequency formula is given by
the data sheet, on page 422 at the bottom of the page:
Quote: | FMAX = (16.36 MHz/V) (VDDAPPMIN – 2.0V) + 4 MHz |
That gives:
(16.36 * 1.3) + 4 = 25.268 MHz maximum freq for the "LF" version at 3.3v for Vdd.
So you could use a 20 MHz crystal but you must buy the "LF" version of
the PIC and install it on your board. |
|
|
|
|
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
|