0
\$\begingroup\$

I am trying to setup communication between my MCU and slave chip but here are the results from logic analyzer:

enter image description here

I have basic knowledge of SPI protocol but as far as I know, data should be sampled at every clock's phase change. Samples are obviously missed on MISO line. What could possibly go wrong?

Edit 1

My slave device is X-NUCLEO-IDB05A1

Edit 2

Problem solved: MISO signal is stable when I work on laptop's battery... It looked very poor on the oscilloscope - that gave me a hint.

\$\endgroup\$
11
  • 1
    \$\begingroup\$ What slave chip? Please provide a link to the datasheet. (Edit the question to clarify, new readers shouldn't have to read comments to understand the question). \$\endgroup\$
    – The Photon
    Commented May 23, 2016 at 2:25
  • 2
    \$\begingroup\$ If you read the wiki article on SPI, you'll see there's at least 4 variations on how master and slave should respond to the clock signal. Likely your peripheral is using a different "mode" than you are expecting. Once you figure out what mode your peripheral is designed for, you should be able to fix up your uC code to deal with it. \$\endgroup\$
    – The Photon
    Commented May 23, 2016 at 2:30
  • \$\begingroup\$ Looks like mode 3. \$\endgroup\$
    – SoreDakeNoKoto
    Commented May 23, 2016 at 2:54
  • 2
    \$\begingroup\$ A signal that changes on both rising and falling clock edges is in violation of all four SPI modes. Are you sure the slave is SPI compatible? What is the slave? Can you really trust your analyzer? \$\endgroup\$
    – Mark
    Commented May 23, 2016 at 4:08
  • 2
    \$\begingroup\$ It would be good to use a scope instead of a logic analyzer, as you may well see analog "evidence" of various failures. Even a non-storage scope should work if you make the program execute an SPI operation in a tight loop. \$\endgroup\$
    – Chris Stratton
    Commented May 23, 2016 at 14:44

1 Answer 1

Reset to default
1
\$\begingroup\$

The only way I can attempt to explain your logic analyzer trace is to guess you are going from a 2 wire SPI master to a 1 wire SPI slave and that the slave is configure to a different mode (master changes on falling edge and latches on rising edge / slave is changing on rising edge and latching on the falling edge) and (I'm not finished yet) you have the slave's resistors wired up wrong so that the only way the slave's MISO line is active is when the master's MOSI line is pulling it high.

We can't tell exactly which of the 4 modes the master or slave are operating in because we can not see the Chip Select line.

Added later...

Apologies, the mode of the master is 3. The sense of the CS is not part of the mode definitions according to this.

The STMicroelectronics evaluation board, if unmodified, is unlikely to contain an error. The BlueTooth module and the EEPROM on the evaluation board, according to the schematic, are both 2 wire (independent MOSI & MISO pins) devices. However, the SPBTLE-RF specification does not specify a SPI mode. Nor does it have a SPI wave form to study.

Even though this is an evaluation board it is unlikely to contain an error. The SPI logic analyzer trace posted does not appear correct. This only leave a hand full of possibilities:

  1. Logic analyzer test is incorrect. Check connections and verify the correct signal are being monitored.

  2. The hardware has been modified or damaged. Use only the hardware necessary. Remove any extra (Arduino) shields. If possible, swap out the controller with a known working controller. Leave jumpers in their default configuration.

  3. The software has been modified or corrupted. Use the latest version of code from STMicroelectronics designed to work for your version of the controller and demo board. Do not modify the software or (if any) default configurations.

\$\endgroup\$
6
  • \$\begingroup\$ Chip Select is low when transmission starts (CS low - 5 bytes transfered - CS high) \$\endgroup\$
    – joe.kovalski
    Commented May 23, 2016 at 8:35
  • \$\begingroup\$ Are you checking the CS for the Bluetooth module or for the EEPROM? Are you using the STM32 MCU Nucleo board as the controller? \$\endgroup\$
    – st2000
    Commented May 23, 2016 at 12:21
  • \$\begingroup\$ I am using STM32L152 eval board and checking CS for the Bluetooth module. I have checked results with two logic analyzers and with two X-NUCLEO-IDB05A1 boards. \$\endgroup\$
    – joe.kovalski
    Commented May 23, 2016 at 12:26
  • \$\begingroup\$ Assuming you are running up to date software on the controller and demo board. I would say it is time to contract STMicroelectronics: st.com/content/st_com/en/contact-us.html. See if there is a Field Service Engineer in your area. \$\endgroup\$
    – st2000
    Commented May 24, 2016 at 2:24
  • \$\begingroup\$ I might also try STMicroelectronics forums: my.st.com/public/STe2ecommunities/mcu/default.aspx \$\endgroup\$
    – st2000
    Commented May 24, 2016 at 2:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.