strange problem with SPI1 on STM32F7 with SPI mode3

[tridge]

We've hit a strange issue with mode3 SPI transfers on SPI1 on STM32F7xx boards. For some really bizarre reason everything works great for mode0 devices, but not for mode3. Devices that work on both mode0 and mode3 will only work on mode0. The problem doesn't happen on SPI2 or SPI4.
We've seen the problem on STM32F745, STM32F765 and STM32F777 boards. In a debugger what happens is that the osalThreadSuspendS() in spiExchange never completes. We've never had a problem with STM32F4xx boards.
We think we are setting up CR1 correctly (it's not exactly hard ...), so what could it be?
We don't as yet have bus traces to see what is happening on the pins (the boards we are dealing with make it quite tricky to get at SPI1 with a logic analyser).
I've walked through the STM32 SPIv2 driver and I can't see anything that could possibly cause this. Apart from getting a good bus trace, does anyone have any suggestions?
The problem happens with both the latest ChibiOS trunk build, and the older version we are currently using in ArduPilot.
One possible clue is that due to the DMA sharing system we have in ArduPilot we call spiStop() and spiStart() a lot as we pass the DMA channel over to other devices. I don't see how it accounts for the problem, but it is the most unusual aspect of how we use the ChibiOS SPI drivers.

[Giovanni]

It could be a bug, could you submit a simple project I can test? just a call to SPI that does not return. A modification to the SPI test application would also do.

Giovanni

[tridge]

It could be a bug, could you submit a simple project I can test? just a call to SPI that does not return. A modification to the SPI test application would also do.

That's very kind of you, all I was really wanting was some hints if you had any, or perhaps you'd heard of the issue. I've ordered a Nucleo-F767 board which should be here in the next day or two, and that will make it easy for me to get bus traces showing what is going on. I'll quite enjoy trying to track this down, so I'll hold off on making an example app for you until I've had a chance to look at it on the nucleo board.
Cheers, Tridge

[Giovanni]

It could be related to initialization order of bits in control registers, or something low level like this.

Giovanni

[tridge]

A bit more info. Mirko Denecke has got some traces with a Saleae using a mpu9250 on SPI1 and SPI2, with Mode0 and Mode3. Logs here:
https://drive.google.com/open?id=1n-7Re ... 7tQ2HQQTK6
I've attached an image showing the same transaction using Mode3 on SPI1 and SPI2, taken from his logs.
It looks like the first clock pulse on SPI1 is missing in the 2nd transaction. It only clocks 15 bits, and the alignment of the MOSI data suggests that it is the first clock pulse that is missing.
Thanks for the suggestion of the ordering of the register writes. We'll try changing that.
Cheers, Tridge

[tridge]

the mystery deepens ...
We've now rebased on 18.2.x stable branch, and now SPI Mode3 is working on SPI1. I could have sworn I tested it with trunk a couple of days ago and it didn't work, but trunk and 18.2.x stable are identical for SPIv2.
All I can think is that I screwed up the test on trunk, and that it was this bug fix that fixed it:
https://sourceforge.net/p/chibios/bugs/879/
The description seems to fit the symptoms shown in the trace.
I've tested 18.2.x stable branch on two boards (both STM32F765) and they both work. I'll try a F745 now.
Cheers, Tridge

[Giovanni]

I need to check if that bug has really been fixed in all branches because it really looks what it is described there, or maybe, it is not entirely fixed for some reason.

Giovanni

[tridge]

I need to check if that bug has really been fixed in all branches because it really looks what it is described there, or maybe, it is not entirely fixed for some reason.

yes, it matches the logic analyser traces perfectly, but what I don't understand if this was the bug is why the DMA didn't complete. It should have just resulted in one failed sensor, with garbage coming back for the later data (or maybe always 0xFF ?)
Are we missing a timeout?

[Giovanni]

Not sure about that, need something to debug with the analyzer attached.

Giovanni

[gsobczak]

I've had a similar problem with spiSend halting on osalThreadSuspendS() on STM32F429zi after migrating my code from ChibiOS 17.6 to 18.2. The cause was in SPIConfig struct. The difference in hal_spi_lld.h between those versions was:

Code: Select all

#if (SPI_SUPPORTS_CIRCULAR == TRUE) || defined(__DOXYGEN__)
  /**
   * @brief   Enables the circular buffer mode.
   */
  bool                      circular;
#endif

So after adding "false," at beginning of the SPIConfig struct problem was solved. Maybe You have the same problem.