Broadcom: Can't set baudrate on SPI bus

[rsbohn]

CircuitPython version

Adafruit CircuitPython 7.2.0-alpha.1-132-gba008ddfb on 2022-01-18; Raspberry Pi Zero W with bcm2835

Code/REPL

import board
import busio

def test(n=1_000_000):
    bus = busio.SPI(board.SCK, board.MOSI, board.MISO)
    with bus as spi:
        while not spi.try_lock():
            print("no lock")
        spi.configure(baudrate=n)
        spi.unlock()
        print(f"frequency={spi.frequency}")
    bus.deinit()
test()

Behavior

It reports the frequency as zero.

I can run test() multiple times on other devices, but on the Pi Zero W the second and later times I run it I get:

  File "<stdin>", line 1, in <module>
  File "test_spi.py", line 6, in test
ValueError: Invalid pins

Description

Sometimes I get fast SPI (24 MHz). But if I get zero I have to do a hard reset.

Also something isn't getting released by deinit().

I'm trying to use the PiTFT 1.14" display. I have to cycle power until I get the fast SPI bus.

Additional information

No response

[dhalbert]

This might be similar to #5836.

[rsbohn]

It does look to be the same. Should I write a new issue for deinit() not releasing the pins?

[tannewt]

The 0 frequency may be a result of the GPU not responding to us with the base clock speed. I think there is some unreliability with the mailbox interface that I don't know how to fix.

[thezim]

For more context on #5836

https://forums.adafruit.com/viewtopic.php?f=60&t=187138

[tannewt]

Again, I don't think this is the same as #5836. That is on the RP2040, not the broadcom chips. I believe this issue is due to fetching the source clock from the GPU. It seems to be unreliable which is why this sometimes works.

[RetiredWizard]

I've been poking and prodding this for the last 2 weeks and I've come to the conclusion that there is something going on with the VCMAILBOX_TAG_GET_CLOCK_RATE_MEASURED function with the CORE clock specified on the VideoCore that is hanging the mailbox registers. Once you send the CLOCK_RATE_MEASURED request to the VC I've been seeing something like an 80% chance the registers will hang and from then on, no mailbox requests of any type can be processed. Perhaps the CORE clock can be in a state that prevents it being measured and the mailbox code just waits forever for the measurement to complete. There seems to be an early measurement processed during CircuitPython startup that doesn't run into the issue so I'm thinking that as CP starts up it modifies the core clock behavior somehow. Edit: Actually the early call is on the UART clock not the CORE clock so that's probably not relevant

I have replaced the VCMAILBOX_TAG_GET_CLOCK_RATE_MEASURED with VCMAILBOX_TAG_GET_CLOCK_RATE (actually, I just changed the measured ID to the unmeasured value so the change is applied to every instance) and I'm getting a stable value that doesn't hang the registers.

The descriptions in the mailbox header file for the two messages are:

VCMAILBOX_TAG_GET_CLOCK_RATE
// Get clock rate
//
// Next enable rate should be returned even if the clock is not running. A rate
// of 0 is returned if the clock does not exist.
//

VCMAILBOX_TAG_GET_CLOCK_RATE_MEASURED
// Get clock rate measured
//
// Get the true/actual clock rate (instead of the last requested value returned
// by "Get clock rate"/0x0003002) which respects clamping, throttling and clock
// divider limitations.
//

I've done some internet searching but haven't found anything that would detail what's happening on the VC when the _MEASURE request is made. I guess the disadvantage of using the unmeasured clock is that if the clock is slowed down or overclocked the value would be incorrect. Perhaps if CP supports clock throttling or overclocking we could capture the settings and adjust the results from the mailbox call.