RP2350: SPI with DMA seems not working

[advancedlogic]

First of all, thanks for the amazing effort to develop TinyGo.
I am creating a library to experiment with the Geeek Pico Breadboard https://github.com/geeekpi/pico_breadboard_kit using the RP PICO 2 (RP2350).

• NeoPixel: OK
• Joystick: OK
• Leds: OK
• Buzzer (Speaker): KO, PWM seems not yet available for RP PICO 2
• Display (ST7796U): OK but without DMA
• Touch: Not implemented yet

I was able to modify the driver ST7789 to work with the ST7796U (480x320) but if I try to use the method Tx(w,r []byte) with more than 1 byte, the PICO 2 freezes during the initialization process and I did not find a way to understand why. Everything works if I send each byte using Transfer (but it's slow for a decent refresh rate). - https://github.com/tinygo-org/tinygo/blob/release/src/machine/machine_rp2_spi.go

I also tried with an ST7789 using the driver available https://github.com/tinygo-org/drivers/tree/release/st7789, with the RP PICO 2 and it freezes during the initialization process.

It seems related to the DMA access. In the RP2350 Datasheet it seems that for payloads less than 250MB it should be retro-compatible with RP2040 but the DMA SPI addresses seem different. I maybe wrong (I am not an expert in microcontrollers)

[advancedlogic]

I don't think the behavior is supposed to be this one, but I managed to make it work, transferring 4 Bytes at the time:

func (d *DeviceOf[T]) sendCommand(command uint8) error {
	d.dcPin.Low()
	d.csPin.Low()
	err := d.bus.Tx([]byte{command}, nil)
	d.csPin.High()
	return err
}

func (d *DeviceOf[T]) sendData(data []byte) error {
	d.dcPin.High()
	d.csPin.Low()
	for i := 0; i < len(data); i += 4 {
		end := i + 4
		if end > len(data) {
			end = len(data)
		}
		if err := d.bus.Tx(data[i:end], nil); err != nil {
			return err
		}
	}
	d.csPin.High()
	return nil
}

[hb9cwp]

@advancedlogic Which SPI port are you using, e.g. SPI0 or SPI1?

The st7789 driver gets stuck doing DMA while initialising a "Pico-LCD-1.14" 135x240 display from Waveshare with a Pico 2W (RP2350) resp. DMA channel. This setup comes prewired so that the LCD uses SPI1 which is associated with DMA channel 1.
Using GDB and OpenOCD with RPi Debug on the SWD bus, I observe that DMA appears to wait forever upon the very first call to func (spi *SPI) tx(tx []byte) error { }

After a quick look at this code, while lines 298 and 301 take care of the DMA channels being different for SPI0 and SPI1, line 315 appears to currently cater for SPI0 only (rp.DMA_CH0_CTRL_TRIG_...), but not yet for setups with SPI1 which uses DMA_CH1 instead?

While this seems to be the root cause, I have patched a local fork of the st7789 and rewrote the implementation of its fillRectangle() to avoid DMA by unrolling the bulk transfers by d.bus.Tx() to repeated, character-wise Transfer() calls. Like in your case, this "band aid" got me past the initialisation of the LCD by st7789, although much less efficient.

Over the next few days, I might try to address the root cause and then test st7789 with DMA again.

[hb9cwp]

@kenbell @deadprogram @aykevl Where can I find src/device/rp/*.go which tinygo/.gitignore excludes from the source tree since Commit cfbc9be?

I would like to understand the problem with DMA in func Tx() when it uses SPI bus 1 and DMA channel 1 as described above and then attempt to fix it. Thank you.

[deadprogram]

@hb9cwp those files are generated from the SVD files for each architecture.

You can generate them by running make gen-device

[hb9cwp]

Thanks - It would be handy to have the 'src/device/' files in the source tree on Github for quick reference, search and cross-reference (including older versions), without having to set up a Dev environment first.

[hb9cwp]

Finally, I got my LCD working with the st7789 driver with SPI bus 1 using DMA on a Pico 2W. The problem is that the numbers for the DREQ lines on RP2350 differ from RP2040.
Those DREQ lines provide "handshaking" that allows a SPI bus to throttle a DMA channel ("flow control") in tx() of :tinygo/src/machine/machine_rp2_spi.go:

if spi.Bus == rp.SPI0 {
	ch = &dmaChannels[spi0DMAChannel]
	dreq = 16 // DREQ_SPI0_TX
} else { // SPI1
	ch = &dmaChannels[spi1DMAChannel]
	dreq = 18 // DREQ_SPI1_TX
}

However, in the generated src/device/rp/rp2040|rp2350.go files or anywhere else in 'machine', I could not find any definitions for DREQ_SPI0_TX and DREQ_SPI1_TX.

Thus one way to fix the SPI driver so that DMA works also on RP2350 is:

//go:build rp2040
        if spi.Bus == rp.SPI0 {
                ch = &dmaChannels[spi0DMAChannel]
                dreq = 16       // DREQ_SPI0_TX RP2040
        } else { // SPI1
                ch = &dmaChannels[spi1DMAChannel]
                dreq = 18       // DREQ_SPI1_TX RP2040
        }

//go:build rp2350
        if spi.Bus == rp.SPI0 {
                ch = &dmaChannels[spi0DMAChannel]
                dreq = 24       // DREQ_SPI0_TX RP2350
        } else { // SPI1
                ch = &dmaChannels[spi1DMAChannel]
                dreq = 26       // DREQ_SPI1_TX RP2350
        }

A somewhat opaque but more compact but more opaque solution is to use 'rp2350ExtraReg' which is =0 for RP2040 or =1 for RP2350, already used to define the number of available dmaChannels:

        if spi.Bus == rp.SPI0 {
                ch = &dmaChannels[spi0DMAChannel]
                dreq = 16 + (24-16)*rp2350ExtraReg
        } else { // SPI1
                ch = &dmaChannels[spi1DMAChannel]
                dreq = 18 + (26-18)*rp2350ExtraReg
        }

More sustainable would be to add new constants to tinygo/src/machine/machine_rp2_2040.go:

DMA_DREQ_SPI0_TX = 16 
DMA_DREQ_SPI0_RX = 17 
DMA_DREQ_SPI1_TX = 18
DMA_DREQ_SPI1_RX = 19 

and to 'tinygo/src/machine/machine_rp2_2350.go':

DMA_DREQ_SPI0_TX = 24
DMA_DREQ_SPI0_RX = 25
DMA_DREQ_SPI1_TX = 26
DMA_DREQ_SPI1_RX = 27

Then the fix is simple:

        if spi.Bus == rp.SPI0 {
                ch = &dmaChannels[spi0DMAChannel]
                dreq = DMA_DREQ_SPI0_TX
        } else { // SPI1
                ch = &dmaChannels[spi1DMAChannel]
                dreq = DMA_DREQ_SPI1_TX
        }

[eliasnaur]

Thanks for debugging this. I lean towards adding the constants to machine_rp2_xxxx.go files. Remember to unexport the constants with an underscore or similar.

[hb9cwp]

Thanks for the merge. After building LLVM and TinyGo from sources yesterday, I can confirm that it fixes the issue between DMA and SPI on RP2350: tinygo version 0.38.0-dev-3f4f4e0e linux/amd64 (using go version go1.24.2 and LLVM version 19.1.2).
Although DMA transfers to the LCD now work without further changes, I might propose another PR for the ST7789 display driver. While debugging, I noticed a few timing parameters which appear a bit "aggressive", notably in the inititialization of the ST7789 and LCD where it does not really affect performance, when compared to the ST7789WV datasheet and its implementation in CircuitPython.