SPI DMA problems

[TomFahey]

Intention

So I have been trying to see whether I could use the new DMA micropython module to interface a MAX31865 SPI RTD sensing chip to a Pico 2, in such a way that I can periodically read temperature values from the chip and write them to a memory buffer, all with essentially no intervention with the main processor.

Code

After a fair bit of reading of the RP2350 datasheet, I was able to come up with the following code:

# Constants
SPI1_BASE = 0x40088000
SSPDR_OFFSET = 0x008
SPI1_SSPDR = SPI1_BASE + SSPDR_OFFSET  # SPI1 data register

DREQ_SPI_RX = 27 # Receive DREQ for SPI->DMA
DREQ_SPI1_TX = 26 # Transmit DREQ for SPI->DMA

# Read and write registers
tx_data = bytearray([0x01, 0x00, 0x00, 0x00]) # Address to read on MAX31865 chip
rx_data = bytearray(4) # Buffer to write temperature data to

# Setup DMA channels
tx_dma = rp2.DMA()  # DMA controlling output of SPI MOSI
rx_dma = rp2.DMA()  # DMA receiving input of SPI MISO

# SPI chip select pin
cs_1 = Pin(SPI_CS_PIN_1, mode=Pin.PULL_UP)
cs_1.value(1)

# Configure DMA channels
tx_config = tx_dma.pack_ctrl(
    size     = 0,      # 8-bit transfers
    inc_read = False,  # always read tx_data
    inc_write = False, # always write to SPI1_SSPDR
    treq_sel = DREQ_SPI1_TX  # pace transfers according to when byte is sent on SPI bus
)
rx_config = rx_dma.pack_ctrl(
    size      = 0,
    inc_read = False, # always read from SPI1_SSPDR
    inc_write = True, # update each byte of rx_data
    ring_size = 2,    # wrap back to start of rx_data after 4th bit,
    ring_sel = True,  # apply ring address mask to write address
    treq_sel = DREQ_SPI1_RX  # pace transfers according to when byte is received on SPI bus
)
tx_dma.config(
    read = tx_data,     # Address of register to read on MAX31865
    write = SPI1_SSPDR, # SPI1 data register => SPI1 TX FIFO
    count = 4,          # transfer 4 bytes
    ctrl = tx_config,   # DMA control register data
    trigger = False     # Don't start SPI transaction yet
)
rx_dma.config(
    read = SPI1_SSPDR, # SPI1 data register <= SPI1 RX FIFO
    write = rx_data,   # Received temperature value
    count = 4,         # transfer 4 bytes
    ctrl = rx_config,  # DMA control register data
    trigger = False    # Don't start SPI transaction yet
)

def write_spi():
    cs_1.value(0)     # Low enable chip select
    tx_dma.active(1)  # Send address bytes to SPI controller
    cs_1.value(1)     # Stop transaction

# SPI transaction
rx_dma.active(1) # Start listening for bytes to be read in by SPI controller
write_spi()      # Start SPI transaction

which I was very happy to see would result in the appropriate temperature (resistance, actually) value appearing in rx_data.

Problem

The only problem is, after the first transaction, attempting to restart rx_dma fails, with 0x00 bytes being written to rx_data,

# First transaction:
rx_dma.active(1) # Returns True (as expected)
rx_dma.active()  # Returns True (as expected)
rx_dma.count     # Returns 4  (as expected)

write_spi()                   # actual data:  v     v    
rx_data   # Returns correct data e.g [0x00, 0x40, 0xbe, 0x00] (as expected)

rx_dma.active()  # Returns False (as expected)
rx_dma.count     # Returns 0 (as expected)
tx_dma.active()  # Returns False (as expected)
tx_dma.count     # Returns 0 (as expected)

# Attempt second transaction:
rx_dma.active(1) # Returns False (unexpected)
rx_dma.active()  # Returns False (unexpected)
rx_dma.count     # Returns 0 (unexpected)
rx_data          # Returns [0x00, 0x00, 0x00, 0x00] (unexpected)

and I am unable to re-activate the receive DMA channel (or, when it is activated, it immediately thinks it has received 4 0x00 bytes and stops?)

Funnily enough, I found that if I used the Micropython SPI module to perform the same SPI read at this point e.g

spi = SPI(...)
cs_1.value(0)
spi.write(0x01)
spi.read_into(rx_data)
cs_1.value(1)

then rx_dma and tx_dma go back to their original state and I am successfully able to call

rx_dma.active(1) # Returns True

once again. However, if I call write_spi() again, the DMA channels go back to the 'unresponsive state' and I'm back at square one.

The issue?

Having looked at the C code in ports/rp2/machine_spi.c (specifically machine_spi_transfer()), it's unclear to me what I'm doing different which is preventing me from restarting the DMA channel. I can see that the Pico SDK function dma_channel_wait_for_finish_blocking() is called at the end of machine_spi_transfer(), however as far as I can tell, all that does is prevent the read address being accessed while the DMA transfer is taking place.

My hunch, having read the RP2350 datasheet, was that this might have something to do with IRQs being generated by the SPI controller which are cleared when the read and write functions of the standard SPI module are used.

Investigating the status registers for the SPI 1 controller whilst it was in its 'working state', I noticed that the following two registers:

• SSPSR (Status register)

  Bits	Description	Type	** Reset
  31:5	Reserved	-	-
  ...	...	...	...
  2	RNE: Receive FIFO not empty	RO	0x0
  1	TNF: Transmit FIFO not full	RO	0x01
  0	TFE: Transmit FIFO empty	RO	0x01

• SSPRIS (Raw interrupt status register)

  Bits	Description	Type	** Reset
  31:4	Reserved	-	-
  3	TXRIS: Raw interrupt state of SSPTXINTR	RO	0x1
  2	RXRIS: Raw interrupt state of SSPRXINTR	RO	0x0
  1	RTRIS: Raw interrupt state of SSPRTINTR	RO	0x01
  0	RORRIS: Raw interrupt state of SSPRORINTR	RO	0x01

had different values when in the 'unresponsive state':

# Working state
bin(machine.mem32[SPI1_SSPSR]) # Returns 0b11
bin(machine.mem32[SPI1_SSPRIS]) # Returns 0b1000

# Unresponsive state
bin(machine.mem32[SPI1_SSPSR]) # Returns 0b111
bin(machine.mem32[SPI1_SSPRIS]) # Returns 0b1110

I wasn't sure if this is the reason I'm not able to reactivate the DMA channels - because the SSPRXINTR/SSPRTINTR interrupts remain asserted? The thing is, I'm not sure how to de-assert them; writing 0x3 to the interrupt clear register, SSPICR, doesn't seem to do anything.

I should note that both DMA channels are set to irq_quiet=True - the default setting in the rp2.DMA module.

[TomFahey]

Ok, I think I've worked out the problem here.

I think my use of the standard SPI module together with the direct DMA configuration may have caused a conflict, with SPI trying to use the same DMA channels as my code above (channels 0 and 1).

After deleting all the python objects instantiated from the SPI module, when I created two new rp2.DMA objects, they were assigned to DMA channels 4 and 5. Using these channels, the unresponsive state doesn't appear and I was able to reactivate rx_dma multiple times without any problems.

Testing this theory a bit further, I tried creating and deleting the rp2.DMA instances assigned to channel 0 and 1 and then creating two new ones, assigned to channel 2 and 3. I was again able to use these successfully, without deleting the SPI instance - which suggests that it is possible to use the standard SPI module alongside user DMA control of the SPI controller, as long as they use different DMA channels (and both parts don't try to access the SPI controller at the same time, of course).

It is a little surprising that the rp2.DMA module doesn't automatically check that a DMA channel isn't being used by a different object when it assigns a channel to a newly created DMA object. I think it would be helpful if users could specify which DMA channel they wish to use e.g

rx_dma = rp2.DMA(5) # Use DMA channel 5

in order to avoid these kind of conflicts.

[peterhinch]

A couple of queries (from a non-expert)

tx_config = tx_dma.pack_ctrl(
    size     = 0,      # 8-bit transfers
    inc_read = False,  # always read tx_data
    inc_write = False, # always write to SPI1_SSPDR
    treq_sel = DREQ_SPI1_TX  # pace transfers according to when byte is sent on SPI bus
)

Shouldn't inc_read be True to read successive bytes of tx_data?

There may be a race condition here:

def write_spi():
    cs_1.value(0)     # Low enable chip select
    tx_dma.active(1)  # Send address bytes to SPI controller
    cs_1.value(1)     # Stop transaction

If cs goes to 1 before the DMA is finished the receiving chip will probably ignore further data. Probably unlikely with 4-byte transfers but still...

[TomFahey]

Shouldn't inc_read be True to read successive bytes of tx_data?

Yes, it should - well spotted. That was a silly mistake on my part.

I think I left it as inc_write = False because I previously tried to use size = 2 (i.e have the DMA controller read the whole 4-byte tx_data buffer at once and then clock each byte out to MOSI), before seeing that the code for machine_spi_transfer() used size = 0.

Luckily this hasn't affected my current use, as the MAX31865 only listens for the first address byte during reads (the subsequent bytes are ignored), although I dare say it may have caused considerable frustration down the line!

There may be a race condition here

My use case is just reading/writing a couple of bytes and the SPI clock is set to 5MHz, so thankfully timing hasn't been an issue here.

Since I got the DMA config working, I've moved the control of the chip_select pins to a PIO routine, which acts as a timer, periodically triggering tx_dma using the PIO's DREQ:

@rp2.asm_pio(set_init=rp2.PIO.OUT_HIGH)
def read_max31865():
    # Cycles: (1 + 23) = 24
    set(x, 31)                  [23]
    wrap_target()
    # Cycles: 32 * ((1 + 29) + (1 + 30) + (1 + 30) + 1) = 2976
    label("counter")
    nop()                       [29]
    nop()                       [30]
    nop()                       [30]
    jmp(x_dec, "counter")
    # Cycles: 2 + 4*3 + 1 + (1 + 6) + 1 + 1 = 24
    set(pins, 0)
    set(x, 31)
    in_(x, 32)
    push(noblock)
    nop()
    in_(x, 32)
    push(noblock)
    nop()
    in_(x, 32)
    push(noblock)
    nop()
    in_(x, 32)
    push(noblock)
    nop()
    set(pins, 1)
    nop()						[6]
    irq(rel(0))
    set(x, 31)
    wrap()

sm = rp2.StateMachine(0, read_max31865, freq=600000, set_base=Pin(CS_PIN))

The period between temperature readings can be adjusted by simply changing the frequency of the state machine - it handled reads every 5ms with no problems. The time intervals between subsequent readings is also very consistent and precise, varying on average by no more than +/- (3-4) us.

A couple of queries (from a non-expert)

Jesus, what does that make me then? A ham sandwich?

[peterhinch]

non-expert

Well, I've never actually used RP2 DMA :)