 |
 |
| View previous topic :: View next topic |
| Author |
Message |
[email protected]
Joined: 28 Jul 2014
Posts: 38
|
| i2c getting stuck |
 Posted: Mon Dec 21, 2020 3:04 am |
 |
|
I am using dspic33ep512mu810.
| Code: |
#use delay(clock=96MHz, crystal=12MHz)
#use i2c(MASTER, I2C2, fast) // hard
|
The I2C DEVICE i am using is MCP23017 I2C port expander.
Some times the i2c gets struck during power on.
How to solve this issue ?
Also suggest any dspic chip that works good in ccs without any bugs. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19555
|
|
| Posted: Mon Dec 21, 2020 7:23 am |
|
|
I don't think there are any PIC's that don't have bugs. However 90%
of the bugs only apply to specific peripherals in particular situations, so
can either be programmed round or ignored. The key thing is to look at
the errata sheet for the chip, and make sure that the bugs avoid the
particular peripherals you want to use.
On your I2C problem, add 'NOINIT' to your #use I2c setup for the device.
Then a little time after boot, send 9 pulses down the SCL line (just
output_low, output_high, with 5uSec between each, repeated 9 times).
Then end by floating the pin, and then use I2C_INIT, with the stream name
involved.
An I2C slave can hang, if the sequencing of the rise on the clock and the
data line are wrong. The 9 clocks is a way of ensuring a slave should
release the bus. |
|
|
kmp84
Joined: 02 Feb 2010
Posts: 357
|
|
| Posted: Mon Dec 21, 2020 2:44 pm |
|
|
Also be sure that you have appropriate pull-up resistors on SCL, SDA lines. In your case for i2c fast speed 2k2 to 3k3. If not need get rid from fast mode.
Best Regards!
Last edited by kmp84 on Tue Dec 22, 2020 4:33 am; edited 1 time in total |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9249
Location: Greensville,Ontario
|
|
| Posted: Mon Dec 21, 2020 7:21 pm |
|
|
As a general comment, you should perhaps code Mr. T's answer into an 'I2Creset' function and run it at the beginning or your code. Similar to #ZERO RAM which put RAM into a KNOWN state. Probably a good idea to clear the HW UART buffers as well as any SW buffers you create.
That way you can avoid any 'weird' problems on startup and/or 'first run through' your code. |
|
|
[email protected]
Joined: 28 Jul 2014
Posts: 38
|
|
| Posted: Tue Dec 22, 2020 5:17 am |
|
|
| Ttelmah wrote: | I don't think there are any PIC's that don't have bugs. However 90%
of the bugs only apply to specific peripherals in particular situations, so
can either be programmed round or ignored. The key thing is to look at
the errata sheet for the chip, and make sure that the bugs avoid the
particular peripherals you want to use.
On your I2C problem, add 'NOINIT' to your #use I2c setup for the device.
Then a little time after boot, send 9 pulses down the SCL line (just
output_low, output_high, with 5uSec between each, repeated 9 times).
Then end by floating the pin, and then use I2C_INIT, with the stream name
involved.
An I2C slave can hang, if the sequencing of the rise on the clock and the
data line are wrong. The 9 clocks is a way of ensuring a slave should
release the bus. |
I must send 9 pulses on the scl and sda are only scl.
| Code: | | #use i2c(MASTER, I2C2,fast,NOINIT) |
is this correct ?
| Code: |
void send_9_pulse()
{
for(int8 a=0;a<9;a++)
{
output_bit (PIN_f5,0);
delay_us(5);
output_bit (PIN_f5,1);
delay_us(5);
}
}
output_float(pin_f5); |
|
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
