Metro M4: SPI baudrate setting results in wrong clock frequency

[deshipu]

I just tested the busio.SPI on the M4, and it works with my display, however, there is a minor issue:

I noticed that the clock frequency doesn't match the baudrate setting. At 48MHz, 32MHz and 24MHz I get a 12MHz clock (as measured with a logic analyzer), and at 12MHz I get 8MHz. At 8MHz baudrate I get 6MHz clock, and so on.

[dhalbert]

Thanks - there could easily be a clocking error. Is this at or after commit 6f662e9, which changed some clock calculations? Do you have an M0 board you could test 3.0 SPI on as well, for clock speed?

[deshipu]

After, I can see that commit in my git log.

[deshipu]

I will test on an M0.

[deshipu]

Exactly the same results on a Feather M0 Express: I can set the baudrate up to 48MHz, but the resulting clock is only 12MHz.

[dhalbert]

And it's wrong on M0 too? 12 MHz is 8 MHz, 8 is 6, etc.?

[deshipu]

Yes, exactly the same numbers. It's wrong both on M4 and M0.

[dhalbert]

Interestingly, with CircuitPython 2.1 I am seeing clock rates that are too high: setting to 6 MHz yields about 8 MHz. 8MHz yields about 12MHz.

[dhalbert]

I figured out what is going on here. The SPI clock rate is determined by a clock going into the SERCOM and by the value of an 8-bit countdown register (the BAUD register). The formula for calculating the value of the register is:

baudreg_value = int(f_clock / (2 * spi_clock_freq)) + 0.5)

The choice of clock frequency determines min and max values of spi_clock_freq, and the steps between the values. On the SAMD21, the max value of f_clock is 48 MHz; on the SAMD51 it is 100 MHz. Currently we use 48MHz on both.

For spi_clock_freq = 100 kHz, the baudreg_value is 240. But once you get into spi_clock_freq in the MHz, the granularity becomes very large, the linearity goes down, and the output frequency is only a rough approximation to what you specified.

(Values from an M0 board)

SPI freq	baudreg_value	measured freq (eyeball avg - Saleae precision is limited)
100 kHz	240	100 kHz
1 Mhz	24	1 MHz
2 Mhz	12	1.85 MHz
3 Mhz	8	2.7 MHz
4 Mhz	6	3.4 MHz
5 Mhz	5	4 MHz
6 Mhz	4	4.75 MHz
7 Mhz	3	6 MHz
8 Mhz	3
9 Mhz	3
10 Mhz	2	7.5 MHz
...	2
16 Mhz	2
17 Mhz	1	11.75 MHz
...	1
48 Mhz	1

As I mentioned, 48 MHz is the maximum SERCOM clock frequency on the M0. On the M4, it's 100 MHz, but if we used 100 MHz, we would overflow the 8-bit register when, say, 100kHz SPI was specified. So 48 MHz is a good compromise.

So I think the conclusion is just make the value as high as possible, for your purposes. The chip has limitations, and it's not possible to get accurate clock frequencies with SPI,which is limited to simple synchronous clock rates. The USART support allows more accurate clock rates at low frequencies. It uses a 16-bit countdown value and can run asynchronously.

[deshipu]

I wonder if it would make sense to have a constant in the busio module specifying the maximum SPI clock speed on the specific board?

[deshipu]

I've read the AN2465 application note about SPI on the SAMD21, and I did some experimenting, and it seems there is an off-by-one error here. If I use this formula instead:

baudreg_value = int(f_clock / (2 * spi_clock_freq)) - 0.5)

I get more consistent values:

spi_clock_freq	baudreg_value
100 000	239
1 000 000	23
...	...
6 000 000	3
8 000 000	2
12 000 000	1
24 000 000	0
48 000 000	0

Which seems to be closer to the actually measured values. Not sure if baudreg_value = 0 is a valid value, though, but I would be extremely happy if it was, because that would let me scroll the screen on my device.

I am going to do some experiments with this.

[deshipu]

On page 436 of the datasheet the formula for calculating baudreg_value (BAUD) is specified as:

which seems to confirm my suspicion.

[deshipu]

I just tested this by adding baud = 0 in asf/sam0/drivers/sercom/sercom.c just after it is calculated, and I do get much faster screen updates with that, though I am currently unable to actually measure this with a logic analyzer.