Hello everybody,
My request is a little bit tricky. Hence, I’ve to apologize for the long explanation of my work and the observed problem (at the end).
Nevertheless, I hope someone can help me with this problem because my collegues and me can’t find a solution.
First, what do I do:
I work with the MyriadRF dev-kit board and the Zipper board since some weeks now to develop a custom LMS6002D software API for Linux.
The API is designed for a ARM CPU and implements direct interaction with the chip via a standard Linux SPI interface (SocketCAN).
Currently, I’m using a Raspberry Pi 3 as test platform. This API should then be used on a spacecraft OBC 
The final system uses a ARM CPU with a built-in SPI controller to communicate directly with the LMS6002D chip.
The API software itself is verified successfully and works fine (no worries here) but I have a strange problem with the SPI communication on hardware level itself since one or two weeks.
Here’s a short description of what I do before I get the problem:
- I connect the Dev-Kit MyriadRF daughter board to the Zipper
- I connect the +5V supplie and the USB cable
- I open the LMS-Suite GUI software - everything works as expected
- Readout with “SPI” module and “Chip->GUI” of all registers -> till here everything is fine
-> as a small test I use the GUI to read register 0x01 or 0x03 several times … - I disconnect the SPI signals on the Zipper Board from the Microcontroller (USB-to-SPI bridge).
-> that required some small adaptions on the Zipper board, I have here high-end soldering equipment, microscopes and all the things and expirence. I’ve simply removee the four “0 ohm” jumper resistors which connect the Clock, MISO, MOSI and Chipselect lines close to the Microcontroller (USB-to-SPI bridge) to disconnect the Microcontroller on Zipper from LSM6002D - I’ve added some jumpers so be able to connect everything again - everything well tested and functional.
-> No worries here, it works and everything is tested with a multimeter, oscilloscope, logic analyzer, etc. - Now I connect my RaspberryPi 3 to the SPI lines which go to the MyriadRF dev-kit and LMS6002D
- After that I can successfully read and write registers with my Raspberry Pi 3 from/to LMS6002D
BUT: now here comes the strange problem
- Readout of Register 0x01 works and replies the power-on-reset default register value - but only ONCE or from time to time!!!
- If I read the register again it returns sometimes 0x00 or some other strange “high” pules while single clock pulse is “high”
-> I’ve verified that the supply was always on, hence no reset. Reset Signal on Zipper is not pulled as well.
-> SPI from Zipper Board Microcontroller (USB-to-SPI) is not interfering because it’s physically disconnected.
-> Reference clock generated with Zipper is running (30.72 Mhz) and was not interrupted
-> always the same behaviour after each power-on reset
-> The SPI communication was verified with an oscilloscope. Signals are acceptable clean and timing requirements are fulfilled.
-> Register 0x15 replies the correct default value only every second readout (0xB0, 0x00, 0xB0, 0x00, …)
-> Raspberry uses pins with lower resistance and MOSI is 1.9V instead of the 3.3V used by MCU if nothing is sent (default). Voltages applied when data is generates are correct with 3.3V and 0V.
With the GUI the read command works every time and does always return the correct value. Nice work!
But why not if I connect a Raspberry Pi 3 and other ARM dev-boards (I have some others)?
SocketCAN SPI code is tested and works with other chips - signal verification in laboratory shows that signals are correct.
The only difference I see on the oscilloscope is the following:
-> The Zipper Board microcontroller introduces a long delay of some microseconds between the two consecutive SPI command bytes (8 clock edges for address, about 8 cycles delay, additional 8 clock edges for replied byte) .
-> The Linux SocketCAN has only a very short delay between both bytes (1-2 clock cycles).
Here some Osci pictures of a read command send 4 times to the LMS6002 which results in 3 times a different reply.
- Read 0x01 -> OK
- Read 0x01 again -> not ok
- Read 0x01 again -> not ok
- Read 0x01 again -> ok
This is only a sample sequence of 4 read commands to show the strange behaviour. The results are different for different registers.
Does the LMS6002D require this long delay between the address byte and the second 8 clock edges (e.g. to set the replied value)??
Is there a more precise SPI specification available with more details to the required timing and voltage levels etc.?
Some idea what the problem could be? Hints for further verification or tests?
Maybe something wrong with the voltage levels?
Maybe we need some pull-up resistors on the SPI lines required?
Maybe there is somewhere a good application engineer or someone else who had that effect once before or can give me some support.
Since it is important and a little bit urgent I would preciate if someone could help me.
Thank’s in advance for your help.
