Extra clock pulses with slow SPI master.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-12 1:40 AM
I wonder if there is some known issue?
With logic analyzer I confirmed that I had extra clock pulses in the SPI after the data was read.
The chip is STM32F427@180MHz.
PCLK2 is 90 MHz
SPI4 (master) is used with 16 bits and with prescaler 64, half duplex, single data line.
I'm reading two 16-bit words with HAL_SPI_Receive(), and after it returns, I turn NSS high.
What I saw with logic analyzer was that after NSS goes high, there were still 16 clock pulses coming out.
When I changed the prescaler even bigger (128), there were no more extra clock pulses.
The chip in the other end has 2 MHz maximum SPI clock.
More accurately:
- chip select LOW
- write 16-bit read command with HAL_SPI_Transmit()
- while receiver is not empty, read DR
- read two 16-bit values with HAL_SPI_Receive()
- chip select HIGH
- 16 extra clock pulses seen
- Labels:
-
SPI
-
STM32F4 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-12 6:46 AM
Is it a one or two-line master?
> while receiver is not empty, read DR
What is this supposed to do?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-12 10:10 AM
Like I mentioned: half duplex, single data line.
The read just removes old crap that may be left there, before reading the data.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-12 10:45 AM
Ahh, I did look but I missed it. Extra clocks in this mode are a recurring issue. The problem is that clocks are sent automatically when RXNE is not asserted, and HAL doesn't stop the transfer until after reading everything, so RXNE is not asserted at the end.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-12 4:47 PM
> The problem is that clocks are sent automatically when RXNE is not asserted,
Are you sure it has anything to do with RXNE? IMO it just churns out clocks - multiples of Data Size - as long as SPE is set.
JW
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-12 11:12 PM
And why does it happen, if prescaler is 64, but not if prescaler is 128? Also note, that I'm using polling HAL-call for receive.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-13 6:15 AM
> Are you sure it has anything to do with RXNE? IMO it just churns out clocks - multiples of Data Size - as long as SPE is set.
You could be right. I'm not very familiar with that mode.
> And why does it happen, if prescaler is 64, but not if prescaler is 128?
It's a race condition in the code. If the rate is slow enough so the CPU finishes first, then you don't get extra clocks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-13 7:06 AM
So the bug is in HAL, not in HW?
(I still doubt that.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-13 8:29 AM
You can't call it a hardware bug if it's working as described in the RM.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2020-11-19 10:12 PM
I think it's HAL that tries to receive more than it's told to, or something like that.
