View previous topic :: View next topic |
Author |
Message |
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
Problem with I2C and delay functions in PIC24FJ64GA306 |
Posted: Fri May 10, 2013 7:06 am |
|
|
Hi! I have PIC24FJ64GA306 connected to a sensor through I2C. I`ve used the sensor before with PIC18F2550, so I have no dоubt in the firmware. PIC24FJ64GA306 is working on 3.3V so I made a MOSFET bridge as the I2C datasheet says. So when I turn on the debugger I successfully intialize the sensor and read data, but when I tried to read data again the controller blocks on the first delay_ms(1) instruction.
Code: |
#include <24FJ64GA306.h>
#FUSES HS,NOWDT
#use delay(clock=20M)
#use I2C(MASTER,I2C1,SCL=PIN_G2,SDA=PIN_G3)
int ReadData()
{
status=0;
i2c_start();
status=i2c_write(sensorAddressWrite);
status=i2c_write(0x00);
i2c_stop();
delay_ms(1);
..........
//instructions for reading data
|
Any ideas what`s happening here? Is there anyking of "misunderstanding" between I2C and delay()?
Thanks! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9221 Location: Greensville,Ontario
|
|
Posted: Fri May 10, 2013 7:32 am |
|
|
I don't use the 24 series but...
1) do you need to first define the 'pin selects' for your use ? newer PICs have 'programmable pins..is yours one of them ?
2) have you tried PCMP's i2c scanner program ? it'll confirm/deny hardware is correct !!
3) why the delay ? if removed does the program run fine
?
hth
jay |
|
|
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
|
Posted: Fri May 10, 2013 10:07 am |
|
|
I don`t need to define CS. The sensor doen`t have SC. When I load I2C scanner, it finds the sensor, but after that it blocks and it can`t do the command i2c_stop() even without delays. What can cause this? |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1345
|
|
Posted: Fri May 10, 2013 3:13 pm |
|
|
I've not used that specific chip before, but have used many of that family (pic24fjxxgaxxx of various types).
Somethings I have found:
1. Check the silicon chip errata for your chip. A lot of these had issues with I2C, though I don't know about yours specifically.
2. On the PIC24fj64ga106, I had to use FORCE_SW on one of my I2C ports to get it to work with an EEPROM.
3. On the PIC24fj64ga004, I had to do some additional line manipulation outside the normal i2c calls to get it to work in slave mode.
That's all that comes to mind at the moment.
EDIT: in terms of blocking, what I find causing that most often is the assembly waiting for a line to change state that never does. Take a look at the assembly for each of the i2c instructions.
Also, he wasn't meaning CS, but "pin select" which is something different. However, on that family most don't need that as I2C is still on dedicated pins (uart and spi, however, typically need the pin select) |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19496
|
|
Posted: Sat May 11, 2013 12:29 am |
|
|
Other comment. You do realise you need separate pull-up resistors on both sides of the MOSFET adapter?.
Lacking these on the PIC side, would cause a hang.
Best Wishes |
|
|
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
|
Posted: Sat May 11, 2013 12:33 am |
|
|
OK! I opened the Disassembly list. The sensor I'm using demands a register address to be send before data extraction. So When I send the address I have to reverse the direction of the data flow. And in this moment my program blocks. When I tried to debug it from this program part:
Code: |
81: data[1]=i2c_read(1);
035E 200011 mov.w #0x1,0x0002
0360 781F81 mov.w 0x0002,[0x001e++]
0362 7800CF mov.w [--0x001e],0x0002
0364 020228 call 0x000228
0368 B7E85F mov.b 0x0000,0x085f
|
The code jumps to the I2C main directive in the top of the program and there it blocks on
Code: |
0246 AE2208 btss.b 0x0208,#1
0248 37FFFE bra 0x000246
|
This is some kind of waiting procedure but I'm not very good in assembler. Can you suppose what's happing here?
I have pull-up resitors on both sides! I tried to connect sensor directly to the controller with pull-up resistors connected to 3.3V. It does the same thing. It reads data one the first run correctly and on the second attempt it blocks!
Best wishes! |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9221 Location: Greensville,Ontario
|
|
Posted: Sat May 11, 2013 5:07 am |
|
|
You should send us the link to the 'sensor'. Maybe someone here has already used it or another pair of eyes scanning the datasheet might see something that you've overlooked.Perhaps the sensor doesen't follow the I2C protocol 100% ?
hth
jay |
|
|
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
|
Posted: Sat May 11, 2013 6:27 am |
|
|
The sensor is new on the market and I`ve taken resposibility in front of the manufaturer not to share the datasheet!
Sorry! |
|
|
jeremiah
Joined: 20 Jul 2010 Posts: 1345
|
|
Posted: Sat May 11, 2013 7:03 am |
|
|
The assembly you posted suggests that the sensor isn't sending the data fully. That leaves at least two options based on the info you provided:
1. Something on the sensor's end
2. Something in the level translation
So try two things:
1. add FORCE_SW to your #use i2c() call
and if that doesn't work:
2. post a clear schematic of the circuit including the PIC, sensor, and wiring |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9221 Location: Greensville,Ontario
|
|
Posted: Sat May 11, 2013 9:02 am |
|
|
Well since you can't tell us about the sensor, the only conclusion I can come up with is that it does not strictly conform to the well documented I2C protocol.
The comment about 'new to the market' hints as being an untested,unreliable unit NOT second sourced(big problem there).
There are obvious 'problem' areas such as timing,pullup values,capacitance,distances,etc. none of which we can comment on.
without knowing the sensor's details....I'm outta here.
jay |
|
|
stoyanoff
Joined: 20 Jul 2011 Posts: 375
|
|
Posted: Sat May 11, 2013 12:25 pm |
|
|
That`s it! I added FORCE_SW and everything is fine!
Thanks a lot! |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19496
|
|
Posted: Sat May 11, 2013 2:03 pm |
|
|
Almost certainly means your bus level translator is not bringing the line high/low properly. The software I2C uses the standard input levels of a PIC pin, which are normally higher for the 'low' level, and lower for the 'high' level, than the I2C spec. So the problem may not be the device.
Best Wishes |
|
|
|