i2c communication with rpi3 Topic is solved

Technical questions regarding the XTC tools and programming with XMOS.
lucami
Member
Posts: 12
Joined: Wed May 09, 2018 1:27 pm

i2c communication with rpi3

Post by lucami »

Hi,
I have difficulities with accessing and setting parameters to my VocalFusion Stereo Dev Kit for Amazon AVS over I2C. I am using raspberry pi 3 with raspbian stretch (kernel 4.14.50). I am following xCORE VocalFusion Control Users Guide to estabilish connection.

Running

Code: Select all

./vfctrl_i2c parameters
exits with error

Code: Select all

rdwr ioctl error -1: Remote I/O error
Error: Control read command failed
The thing is, if I am persistent and issue same command multiple times, on occasion, command is accepted. Which makes me think that the clock signals are not aligned. I am familiar with clock stretching issue in broadcomm chips, but I've been led to believe this issue has been resolved in latest implementations (bcm2835). Additionally, I've tried to reduce I2C baudrate manually with sudo /boot/config.txt changing the dtparam=i2c_arm_baudrate=x, where x has been a number from 5000 to 400000, each resulted in same error described above.

When trying to write parameters with similar approach as above (repetitive commands), I receive this error on the command that was actually successfully issued:

Code: Select all

./vfctrl_i2c BEAMANGLE -0.7071 
Error writing to i2c: -1 of 15 bytes sent
BEAMANGLE:NA
Is anybody familiar with described issue? Any help would be appreciated.


View Solution
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Can only comment at high levels as we do not own the XMOS microphone kit and have yet to unbox the flood of RPI3 boards we have recently sourced through the recent Arrow promotions.

1) Does your I2C wiring have the mandatory pull-up resistors on the I2C_SDA and I2C_SCL lines? Being that the signals are open drain, the pull-ups are required. Cannot recall if the resistors are already present on the RPI3 and/or XMOS board.

2) Watch the length of the wiring although at low I2C speeds should not be an issue.

3) Consider to run an I2C scanner to see if the XMOS I2C slave is being reliably detected - this is perhaps the best suggestion to initiate your debugging:

https://learn.adafruit.com/adafruit-16- ... pi-for-i2c

https://www.raspberrypi.org/forums/view ... p?t=178000

4) If practical, consider to test with another I2C master to rule out the RPI3 as the root cause.

5) Debug with Saleae / Total Phase I2C bus analyzer tools. We have these tools in the lab but the best we can do is to configure a different I2C slave board + RPI3 for any level of testing so the variables would not be the same as yours.
Gothmag
XCore Addict
Posts: 129
Joined: Wed May 11, 2016 3:50 pm

Post by Gothmag »

I believe the RPi still have the I²C clock stretching bug. There have also been alot of similar complaints around. I typically suggest not using the RPi with xmos I2C slave.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. Further to the notes by Gothmag, our younger brother wrote this article on RPI and clock stretching for his Indiegogo campaign and TinyLidar design.

This may help your cause:

http://www.instructables.com/id/TinyLiDAR-on-a-Pi/

Update: Another article that discusses the clock stretching on the RPI and work arounds:

http://www.instructables.com/id/Pi-Base ... st-System/
lucami
Member
Posts: 12
Joined: Wed May 09, 2018 1:27 pm

Post by lucami »

Thank you for your answers. Before I try to sort out clock stretching on rpi, I will try to set parameters with windows.

@mon2
1) The XMOS device has already shipped with wiring attached. I am fairly confident all necessarry pull-ups / pull-downs are in place.
2) Length of wires is couple of cm
3) i2cdetect -y 1 shows connected device at address 0x2c, so this is OK
4) Not practical and as Gothmag mentioned, clock stretching bug is still around
5) Don't have these tools.

As for the links you provided, I may get something useful from pigpio, but at this moment I am not sure.


Additional info for XMOS engineers: I've tried the workaround described in the guide I mentioned in first post and it didn't end successfully. I got stuck at building i2c module with kamdamski's i2c-gpio-param. The error I get refers to i2c-gpio-param.c and is associated to line 127: .class_attrs = i2c_gpio_param_class_attrs, with error message "unknown field .class_attrs specified in initializer" and "initialization from incompatible pointer type".
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

The RPI clock stretching bug is a PITA (and caused a lot of lost engineering time) but.. using bit banged I2C works around it. There is a kernel driver available which looks and feels exactly like the hardware driver which properly supports clock stretching. We use it in the RPI setup scripts for vocalfusion:

https://github.com/xmos/vocalfusion-rpi-setup


Also, worth checking i2c is actually working and you have the slave connected properly:

Use

Code: Select all

 i2cdetect -y 1
If that shows nothing, something fundamental is wrong (not connected properly, firmware not running etc.)
lucami
Member
Posts: 12
Joined: Wed May 09, 2018 1:27 pm

Post by lucami »

@infiniteimprobability as mentioned in point 3, i2cdetect sees my device at 0x2c address. So the connection is OK.

I have been installing the kernel driver that is included in your RPi setup script, but it appears to be outdated, since certain variables are not recognized. I've described errors in my previous post.

Furthermore, some resources on the web indicate that some of the variables have been renamed.
For example: https://github.com/johannesthoma/linux- ... ll/2/files

Though this is source for another driver, there is great similarity with i2c driver included in RPi setup script. When replacing .class_attrs with .class_groups, the issue with .class_attrs variable is resolved. However, i2c_gpio_param_class_attrs still causes error and needs to be changed as well, though I am not sure how.

Here is complete compile log:
pi@raspberrypi:~/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param $ make
make -C /lib/modules/`uname -r`/build M=/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param modules
make[1]: Entering directory '/home/pi/linux-f1a1eec4c38d3c36b67c609f6c27805d04dab978'
CC [M] /home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.o
/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.c:127:5: error: unknown field ‘class_attrs’ specified in initializer
.class_attrs = i2c_gpio_param_class_attrs,
^
/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.c:127:21: error: initialization from incompatible pointer type [-Werro r=incompatible-pointer-types]
.class_attrs = i2c_gpio_param_class_attrs,
^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.c:127:21: note: (near initialization for ‘i2c_gpio_param_class.class_g roups’)
cc1: some warnings being treated as errors
scripts/Makefile.build:334: recipe for target '/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.o' failed
make[2]: *** [/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param/i2c-gpio-param.o] Error 1
Makefile:1522: recipe for target '_module_/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param' failed
make[1]: *** [_module_/home/pi/vocalfusion-stereo-avs-setup/vocalfusion-rpi-setup/i2c-gpio-param] Error 2
make[1]: Leaving directory '/home/pi/linux-f1a1eec4c38d3c36b67c609f6c27805d04dab978'
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2
lucami
Member
Posts: 12
Joined: Wed May 09, 2018 1:27 pm

Post by lucami »

I tried to read parameters with windows using vfctrl_usb.exe and XMOS XTAG interface, but that doesn't work either. I receive error "could not find device". Is there any additional setting I must take care of? There's not enough information in the guide.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

I'd stick with I2C for now if that's the interface you want. The windows setup requies loading a driver installing - not too hard but it won't solve the I2C comms problem.

What versions (exactly) of firmware are you using? For the control to be responsive, the audio must be passing through the system OK. The control requests get polled at the end of each processing block and so no processing, no control poll = control error. In particular, make sure there is an LRCLK and BCLK if you want VF to be the I2S slave. If VF (vocalfusion) is the master, then it will always be looping/streaming.

I'm not sure what is going on with your i2c setup on the RPI - I (and colleagues) have done this dozens of times and it has never failed. Which version of raspian are you running (uname -a I think from memory to check)?
lucami
Member
Posts: 12
Joined: Wed May 09, 2018 1:27 pm

Post by lucami »

I am using latest firmware - installed from VocalFusion-Stereo-AVS-binary_2.2.0rc7.xe.

Raspberry info:

Code: Select all

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

Code: Select all

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.14.50-v7+ #1122 SMP Tue Jun 19 12:26:26 BST 2018 armv7l GNU/Linux
Recording and playing audio is working. Reading and setting parameters is not working. I assume then that the communication at the end of processing blocks is failing, which is probably attributed to failing of i2c-gpio-param driver not properly implementing clock stretching. On which kernel have you successfully loaded this driver?

Regarding LRCLK and BCLK: I haven't changed the wiring that came with VF ready for connecting to raspberry pi. Are you suggesting to check with osciloscope if these clocks are present?
Post Reply