WP7702 using SPI


Hi Madan,

You are not using the right SPI interface.

On mangOH Red, you have two SPI interfaces:

  • One on IOT0 connector (SPI1).
  • One on RPI connector (SPI2).

SPI2 on RPI connector of mangOH is connected to embedded WiFi/BT chipset (MT7697) via USB-to-SPI adapter (CP2130).
MT7697 is using CS0 chipselect from CP2130, but other chipselect signals (CS1 and CS2) are theoretically available to connect other slave devices.
As CP2130 driver is not pre-integrated into Linux system then I would encourage you to use the native SPI1 interface of WP7702 module which is available on IOT0 connector.



What @Jay said is correct. If you need to use the SPI interface on the rpi connector let me know and I will try to help.


Thank you @Jay for the clarifications.

@dfrey, In my setup, IoT slot is occupied. So, I have to use RPI connector to interface other device.
@jay’s response says that SPI on RPi connector used by mt7697. Will there be any conflict with WiFi functionality, if connected to any other device?
Another thing is the procedure for enabling spidev2.

Can we use SPI on RPi along with WiFi and IoT functionality?
If yes, please guide me through the procedure.
If no, please suggest if any alternatives.

Thanks for the support.


The USB bus of the WP module has a cp2130 USB to SPI adapter chip on it. That chip has a number of different chip selects. CS0 of that chip is connected to the mt7697. CS1 and CS2 go to the RPI connector. The process of using the cp2130. So yes, it should be possible to interact with the MAX6675 breakout board using the CP2130 SPI interface in combination with CS1 or CS2 on the RPI connector.

I did a quick search and I found that the MAX6675 is supported by a mainline Linux kernel driver: https://github.com/torvalds/linux/blob/master/drivers/iio/temperature/maxim_thermocouple.c
Unfortunately, this driver doesn’t exist in the WP77 kernel, but it could be backported and then built and loaded by Legato similar to the bmi160 driver. One odd thing about the cp2130 driver is that you have to write to a sysfs file to bind a driver to a chip select and setup the properties of the device. I dug this snippet out of an old e-mail: echo -n 0,2,6,0,0,1,0,0,0,0,0,mt7697 > /sys/devices/platform/msm_hsic_host/usb1/1-1/1-1.3/1-1.3:1.0/channel_config

You would replace “mt7697” with “max6675” in your case. You would likely have to update a number of the other fields as well. You have to look at the cp2130 driver to understand what the numbers mean.


I am using WP7608 on the mangOH. Will there be any change in the command?
I am getting an error - /sys/devices/platform/msm_hsic_host/usb1/… not found.


The command I posted was intended as more of an example than an exact solution. On the wp85 that I’m working on right now, the path is /sys/devices/platform/msm_hsic_host/usb1/1-1/1-1.1/1-1.1:1.0/channel_config. I’m not sure if the location will be exactly the same on a wp76, but you could just do find /sys -name 'channel_config'. Also, the string being written to the file will definitely have to change. It affects the speed, chip select, driver and a bunch of other stuff. See the cp2130 driver source code for an explanation.


First, you need to have the cp2130 driver loaded:

# lsmod
    Tainted: G
cp2130 20478 0 - Live 0xbf000000 (O)

On my WP7607, the channel_config file is available here:



That’s right @Jay . I found the same on my device as well. I can see the ‘channel_config’ file updated, when I ran the command.

echo -n 1,2,-1,0,0,1,2,0,0,0,0,max6675 > /sys/devices/7c00000.hsic_host/usb1/1-1/1-1.1/1-1.1:1.0/channel_config

I was going through @dfrey comments from another post SPI access on Raspberry Pi Connector. Probably intended for WP85. But, one thing - I am also using spiService to get the app talking to the SPI interface. So,

  1. Will @dfrey’s comments (on the other blog post) hold good for me as well?
  2. How will I reference the SPIdevice from the app? spidev1.1 (if chip select CS1 used)? If so, how to get this one instantiated from spiService? Does spiService need a rebuild with some modifications?


spiService is using “spidev” driver.

echo -n 1,2,-1,0,0,1,2,0,0,0,0,spidev > /sys/devices/7c00000.hsic_host/usb1/1-1/1-1.1/1-1.1\:1.0/channel_config

This will create a new spidev device:

Then maybe you will be able to use it with Legato spiService (or a native Linux app):

le_spi_Open("spidev32766.1", &spiHandle);


@jay, I tried with spidev and got the new device /dev/dpidev32766.1 created.
Updated the app and ran. I got an error saying le_spi_Open failed with result=LE_NOT_FOUND.

Did I miss something?


I think you would have to modify the requires section of spiService.adef to include [rw] /dev/spidev32766.1 so that the file is brought into the sandboxed environment.


Thank you @dfrey and @Jay. It’s almost done.
Your suggestions helped to get SPI on RasPi connector function as required.

  • I was able to trace the clock and CS signal on the oscilloscope.
  • The loopback test is successful

I thought it’s all done. But, it is not getting the value from MAX6675 (reading zero always).

As I said, max6675 is working fine on RasPI board. I tried comparing the SPI clock/CS on mangOH and Raspberry PI. The only difference I could find is the length of the CS LOW signal. It’s a bit lengthy on mangOH (~3 times that of RaspPi). However, I don’t see this as an issue, because the data transfer will happen only when CS is LOW (both devices shows 16 clocks for SCLK). I understand they may have different hardware and drivers. But it’s a check to compare.


Please suggest if any other troubleshooting tips and steps to root-cause the issue.
Thank you for the support and guidenace.


As long as the CS does transition from high to low before the clock starts and low to high after the clock finishes, then it shouldn’t matter if there is a bit of extra idle time. From your trace image, it’s not clear whether the CS is actually changing though.

As for why the MAX6675 isn’t working… I’m not sure. Maybe check if there are minimum/maximum clock speeds and check the required polarity and phase settings.



Are you using the correct CS pin?

I’ve done a fair bit of work with the CP2130 - directly using libUSB, not using the onboard SPI service.

The device itself has 10 CS pins, of which 2 are brought out to the RPi connector. If you’re programming the wrong CS pin then you could get what you are seeing.

Also, have you configured the SPI with the correct mode for your device?

ciao, Dave


Hi @dfrey, @Jay and @davidc,

Finally, I got it working on RPi connector with CS1. Happy to share the results.

Working channel_config - echo -n 1,2,-1,0,0,1,1,0,0,0,0,spidev > /sys/devices/7c00000.hsic_host/usb1/1-1/1-1.1/1-1.1:1.0/channel_config


Thank you very much for the guidance and support.

@bobby fyi…



Hello @dfrey,

Need a quick help on initiating the SPI bus on RPi connector.
I was thinking to keep a script file in the init.d.
Would it work?
If it works, will there be any dependency of any driver loading or something?

Idea is before the application starts, i would like to enable the SPI bus and also start the spiService, so that application can go ahead.

Please suggest.



Looking for some ideas here.
Is there a way that this channel_config can be done from boot sequence?



I think you could do it with a startup script in /etc/init.d, but you would have to make sure that Legato had already started because it loads the kernel module for the cp2130.



You could always have a Legato ‘app’ (running unsandboxed) that simply runs the appropriate script and exits.

I’ve added startup shell scripts to legato apps to make sure modules are loaded and so on. Works reasonably well.

ciao, Dave


Hello @davidc,

Thanks for the suggestion and it is inline with what I tried.

I did develop a Leato App to initiate some of the dependencies of our application. One of them is running the spidev32766.1 initialization command as given by @dfrey.
Initially, I tried keeping all the commands in a shell script. However, as it was lacking control on the results/returns, I made them as individual commands and executing from the Legato app. This app runs only once on a reboot.

The steps around this are as below…

  1. execute the command for spi32766.1 (channel_config setup)
  2. Start the spiService
  3. Check for the spi devices (/dev/spi*). Here I expect 2 devices (/dev/spidev.0 and /dev/spidev32766.1)
  4. But for me, at this moment, spiService is failing because it’s not able to create /dev/spidev.0
  5. So, restart the spiService and check again. (Steps 3 and 5 are executed for 5 times before the result is achieved). Mostly for the second or third time, the result is achieved.

Not sure why spiService is failing for the first executed though. (the error is - Failed to set the permissions for spidev.0, as the device is not created).

Though this is not a robust solution, it is working most of the times.

One question is - when a client application fails/terminates, the service also terminates.
Is this by design? How can this be controlled i.e. not to terminate the service?
Idea is to set a fault action to the client application to restart. In this case, the client fails because Service is not running.
Let me know if any suggestions.

@asyal & @Bobby, this is one of the items on the Auto Start Issues that we are trying along with WiFi Configuration at Boot time.