WiPy 3.0 and MPU9250, SPI interface

[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.