We often see Raspberry Pi 3 designed as a cost effective Single Board Computer (SBC) medical device. The Raspberry Pi was originally designed to teach computer science, but has taken off in the open source community as an easy to use and well supported SBC. This blog will focus on an interesting finding in the core clock speed for the Raspberry Pi 3 Compute module (CM) and the default Raspbian image with the impact on Raspberry Pi in medical devices.

The original Pi has been revised multiple times with the latest being the Raspberry Pi 3 Model B. Each generation of the Pi, from 0 to 3, has variations in hardware, specs and clock speeds. If we take a look at the clock descriptions on raspberrypi.org, we can see that the Pi’s GPU frequency is used to set the core frequency which trickles down to setting the serial communication clocks such as the UARTs and SPI. We can also see that the Pi 1 and Pi 2 have a default clock speed of 250 MHz, whereas the Pi 3 and Pi Zero have a default clock speed of 400 MHz.

Now that we have determined what the clock speeds are, let’s take a look at sending some data over the SPI. This is a simple program which increments a number, sends it out the SPI port and then loops.

Figure 1 shows the output from the Pi 3 CM SPI clock and Master Out Slave In (MOSI) Pins. This is the result of attempting to send data at 3MHz. The clock is running and data appears on the output of the MOSI Pin therefore the SPI port works right? Well not quite, the clock frequency is shown to only be 1.85 MHz and not the 3 MHz we had intended. But why?

Let’s recall that the default core frequency of the Pi 3 is 400 MHz, whereas for the Pi 1 and 2 it’s 250 MHz. So what happens if in the device tree in the Raspbian image we set the core frequency to 250 MHz by adding core_freq=250 to /boot/config.txt?

With the device tree updated, the same simple SPI test program is run again at 3MHz. This time, Figure 2 shows the clock frequency is much better at 2.94 MHz. Why does the SPI clock work as expected if the core clock is under clocked to 250 MHz?

Looking at the numbers, if we divide the clock frequencies we have 250/400 or a 0.625. Now do the same with the measure clock frequencies 1.85/2.94 or approximately 0.629. If we allow for a little bit of error in the frequency measurement (I was not using calibrated equipment), we should be able to say that for the Pi 3, at the default core frequency, the peripheral SPI clock is being scaled by a factor of 0.625 or the same ratio as the difference in the default clock speeds of the Pi1/2 and the Pi3/Zero.

This is a known issue and more information can be found in issue #2094 on the raspberry PI github page. The Pi 3 can dynamically change its core clock frequency between 250MHz and 400MHz. Since the UART1, SPI and I2C derive their clocks from the core clock, the serial clocks can also dynamically change.

There is somewhat logical reasoning behind the implementation of this clocking. Take the example where we want to run the serial clocks at 3MHz. If the Pi spends most of its time with a core clock sitting at 250MHz, then the serial clock will actually run at 1.8MHz. When the Pi dynamically increases its core clock to 400MHz, the serial clock will run at the expected 3MHz. However, if the serial clock ran at 3MHz while the Pi is at 250MHz, when the Pi jumps to 400MHz the serial clock will jump to 5MHz. That might not be a problem, but if you are running the serial clocks close to their maximums, then the Pi transitions its core clock and the serial clock could be pushed past its maximum specification.

If we accept the fact that this is a feature we have to live with on the Pi, then we also need to remember that SPI and I2C (which have synchronous clocks) will work fine. UART (which is asynchronous) can get corrupted data transmissions due to the change in clock frequency. If you want to be able to use the UART1 in the Pi and then in the device tree, the core frequency has to be forced to run a single frequency by adding core_freq=250 to /boot/config.txt. You might think that’s silly.  Why wouldn’t you just force it to run at 400MHz? You can, but it’s not advised. Forcing the Pi to run at 400MHz or turbo mode removes its ability to throttle its clock if it detects that the processor is overheating. This will damage your Pi and can also affect your warranty on the Pi.