Hi All,
I’m at a complete loss here. I’m trying to read from an I2C sensor using smbus with the i2c-dev library I’ve included
#include <linux/i2c-dev.h>
#include <sys/ioctl.h>
but at the point of reading from the sensor the kernel crashes and the WP7702 restarts.
I’ve attached my error log and how I read from the i2c bus.
error (6.2 KB)
i2c read (852 Bytes)
any ideas would be greatly appreciated.
Best regards Dan
how about using these existing i2c read command?
root@swi-mdm9x28-wp:~# i2c
i2cdetect i2cget i2cset.i2c-tools
i2cdetect.i2c-tools i2cget.i2c-tools i2ctransfer
i2cdump i2cgpioctl
i2cdump.i2c-tools i2cset
How about running this application in mangoh green board which is also using i2c?
None of those tools seem to support the smbus block read mode. I tried:
i2cdump -y 4 -r 0x12-0x12 0x60 s to read from address 0x12 32 bits on device address 0x60. Says it’s not supported the device I’m trying to read from is an ACS37800 which has 32bit wide registers.
I’ll look into the github example later but that’s where my original code came from anyway.
Thanks for you help.
can you read a word first?
This can isolate if your application has problem (if the command has no problem)
I’m able to read a word without issue.
here says you can read block data by i2cget:
https://manpages.debian.org/unstable/i2c-tools/i2cget.8.en.html
How would I use i2cget within a legato app?
no, i mean if you confirm i2cget has no problem, then this points to your application problem
Then the next step is to port the source code of i2cget in yocto source to your application
Hi Sorry about the late reply I got tied up with other business.
So copied like for like the batterychargerreading example. I get exactly the same kernel crash as previously provided.
I either can understand the command structure of i2cget or it just doesn’t work see below where I try and do an smbus read of 32 bits followed by reading a word.
root@swi-mdm9x28-wp:~# i2cget -y 4 0x60 0x12 c 32
BusyBox v1.31.1 () multi-call binary.
Usage: i2cget [-fy] BUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]
root@swi-mdm9x28-wp:~# i2cget -y 4 0x60 0x12 w
0x0000
as you can see the word works just fine the response for the smbus seems like a malformed command has happened the link you provided does not give an example for smbus cmd c mode.
thanks for the help.
I seem to just get one byte back if I don’t provide a length for smbus read.
Usage: i2cget [-fy] BUS CHIP-ADDRESS [DATA-ADDRESS [MODE]]
root@swi-mdm9x28-wp:~# i2cget -y 4 0x60 0x12 c
0x00
Hi Also I’ve just found out after connecting logic analyser i2c_smbus_read_block_data only reads 2 bytes not 4.
and i2c_smbus_read_block_data returns 0
how about using i2cdump?
root@fx30:~# i2cdump -y 4 0x68 i
0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef
00: d1 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?!..............
10: 00 00 00 00 00 00 00 00 e8 4f 07 10 00 00 00 00 ........?O??....
20: 00 80 00 00 80 80 80 80 80 80 80 80 80 80 80 80 .?..????????????
30: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ????????????????
40: 28 03 28 00 0b 88 80 10 00 00 00 20 80 42 4c 00 (?(.????... ?BL.
50: 00 00 00 00 00 00 00 00 00 00 07 30 81 0b c0 00 ..........?0???.
60: 14 14 24 04 0a 18 48 08 11 00 00 00 00 00 00 00 ??$???H??.......
70: 00 00 00 00 40 85 2b 00 00 00 15 03 00 00 00 00 ....@?+...??....
80: d1 21 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?!..............
90: 00 00 00 00 00 00 00 00 76 51 07 10 00 00 00 00 ........vQ??....
a0: 00 80 00 00 80 80 80 80 80 80 80 80 80 80 80 80 .?..????????????
b0: 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 ????????????????
c0: 28 03 28 00 0b 88 80 10 00 00 00 20 80 42 4c 00 (?(.????... ?BL.
d0: 00 00 00 00 00 00 00 00 00 00 07 30 81 0b c0 00 ..........?0???.
e0: 14 14 24 04 0a 18 48 08 11 00 00 00 00 00 00 00 ??$???H??.......
f0: 00 00 00 00 40 85 2b 00 00 00 15 03 00 00 00 00 ....@?+...??....
root@fx30:~#
Well this method is usable but very cumbersome.
I can send this command via the system command to a file then parse the data out of the file to finally get my specific reading from the address. I would have thought there was a better way. Obviously the only issue is i2cdump is expecting each address to be 8bit but they are 32bit so the numbering that the terminal returns is incorrect.
Obviously the only issue is i2cdump is expecting each address to be 8bit but they are 32bit so the numbering that the terminal returns is incorrect.
you might need to use i2ctransfer
e.g.
root@fx30:~# i2ctransfer -y 4 w1@0x68 0x00 r4
0xd1 0x21 0x00 0x00