WiPy 3.0 and MPU9250, SPI interface

[foxinboxxx]

For my project I need to setup a connection between WiPy 3.0 with an expansion board and MPU9250 sensor via SPI interface, but I'm facing some issues. Here is the wiring:
WiPy ----> MPU9250 sensor:
P14 MISO --> ADO
P11 MOSI --> SDA
P10 SCL --> SCL
P8 CS --> NCS

from machine import I2C, SPI, Pin
import uos


spi = SPI(0, mode=SPI.MASTER, baudrate=1000000, polarity=0, phase=0, firstbit=SPI.MSB)
cs=Pin('P8',Pin.OUT)
cs.value(0)
spi.write(0x75)
data=spi.read(2)
print(data)

The output of the program is

b'\x00\x00'

but the result should be 0x71. Are there some issues in my wiring or in the code itself?

[alvaroav]

@foxinboxxx

Hi!

I am working also with the SPI on the wipy, making use of the default pins (CLK, MOSI and MISO (P10, P11 and P14)
and very simple program like you.

I connected an oscilloscope to the CLK and MOSI signals, and I was very surprised since for any byte I transmit, can be 0x00, 0xff o 0x12, the sent pulses were exactly the same!

It seems that something is wrong with the SPI library or at least, on my code:

from machine import Pin
from machine import SPI

spi = SPI(0, mode=SPI.MASTER, baudrate=10000, polarity=0, phase=0)#, firstbit=SPI.LSB)
led = Pin('G16', mode=Pin.OUT, value=1)
contador=1

while (1):
    led.value(0);
    spi.write(bytes([0x01, 0x02, 0x03, 0x04, 0x05])) # send 5 bytes on the bus
    rdata=spi.read(5) # receive 5 bytes on the bus
    data = rdata + b'  --> Envio N = ' + bytes(str(contador),'utf-8')
    print(data)
    contador += 1
    led.value(1);

[robert-hh]

@alvaroav I do not confirm. Sending like in you script the hex value 1 to 5 looks like the pciture below. The sent values are clearly distinct and the expected ones.

[robert-hh]

@foxinboxxx At first glance, that looks fine, besides that only one byte is to be returned by the MP9250. Are you sure that the MPU is set to SPI mode? Reading the data sheets, the way of accomplishing that reliably is not clear to me.

[robert-hh]

@foxinboxxx Reading more of the data sheet, the high order bot of the address byte tells, whether you read or write. 0 means write, 1 means read. So to read register 0x75, you should send 0x75 | 0x80.

[alvaroav]

@robert-hh

Thanks a lot for your support and quick answer!
Tomorrow I will recheck, also with a new board still on the box, and if necessary with a Wipy2 I have retired some time ago.
It is very strange because I already checked this with 2 different Wipy3 boards, but with the same (latest) firmware.. do you knwo which version of teh firmware do you have?

Thanks a lot! It is a please to find people helping as you!

[robert-hh]

@alvaroav I am using 1.20.0.rc6. But I am pretty confident that the result is the same for 1.18.x.

[alvaroav]

@robert-hh

Dear Robert

I found the bug or unexpected behaviour cause.

I took an out-of-box wipy2 and wipy3, placed them into the expansion boards, and I directly upload the project with Atom.
The results were positive, with output like yours!

Then I upgrade the wipy3 with the latest firmware with "Type = pybytes" --> Firmware version 1.18.2
Once the upgrade finish, the results were like yesterday, with INCORRECT SPI transmission

Then I upgrade the board with the latest firmware "Type = stable" --> Firmware version 1.18.1.r7 ,
and I recover CORRECT SPI transmission

Therefore is clear that there is an issue with the SPI library/driver with the pybytes firmware 1.18.2

Do you know how can I give an alert to someone in pycom?

Thanks for all!!
BR
Alvaro

[robert-hh]

@alvaroav Pycom, namely @Paul-Thornton, is listening at the forum and is taking care, that problems are addressed.

[Paul Thornton]

@alvaroav consider us alerted. I'll pass it on.

Thanks for the @mention Robert.

[alvaroav]

Thanks @Paul-Thornton and @robert-hh

Moreover, I spent some more time looking at the SPI signals.

Now in order to get the correct answer from the slave device, I follow the manufacturer instructions, and send from Master 0x7e, and read 1 byte.

    spi.write(0x7e) # send 1 bytes on the bus
    rdata=spi.read(1) # receive 1 bytes on the bus

The slave replies 0x11 as expected, and now the SPI is working, HOWEVER when writing 0x7e on the MOSI line I can see 01111110 as expected, BUT for the read cycle I also see on the MOSI a 01010101 corresponding to hex 0x55.

Taking into accound the documents related to the SPI:
https://docs.pycom.io/firmwareapi/pycom/machine/spi.html
It is expected that:
spi.read(nbytes, * , write=0x00)
Read the nbytes while writing the data specified by write. Returns the bytes read.

This means that the default write byte should be 0x00, not 0x55.
I also tried to force the write byte to be 0x00 or also different values like 0xff, 0x11, and always see on MOSI line 0x55, never 0x00 nor 0xff nor 0x11

    rdata=spi.read(1,write=0x00) # receive 1 bytes on the bus

@robert-hh

Can you quick check this byte placing just a read 1 byte command on your yesterday test?

Thanks a lot again!!!

[Paul Thornton]

@alvaroav Aha we had a bug in recent firmware causing weird 0x55 values like this. I know it was fixed in the later 1.20 (non pybytes) rc builds. but Ill have to confirm re pybytes builds likely just waiting for the patch to be rolled into the pybytes firmware.

[alvaroav]

@paul-thornton

Thanks again!
I upgrade to the development firmware 1.20.0.rc4, and now the SPI.read is working as expected!!

[Paul Thornton]

@alvaroav Hey glad its working. I've raised it in the team so hopefully the fixes will get ported into the next pybytes firmware release.