PDMin's DMA misses triggers on M0 and M4 occasionally

[ladyada]

@dhalbert can you try running https://github.com/adafruit/Adafruit_Learning_System_Guides/blob/master/Crickits/gear_tower/sound-motor.py
with a DC motor, see if you can replicate some crashes we saw? no REPL was attached, i think it was just a reboot

[dhalbert]

I can get this to crash even without doing any motor setting in the main loop, so I think it's just a PDMIn bug. It randomly stops at some point. I've seen 81 times or a few hundred times go by before it hangs. I'm wiring up a PDM mic with a Metro M0 so I can debug easily.

[tannewt]

This is no longer an issue right?

[dhalbert]

Unfortunately, still is. I can provoke a hang by doing a filesystem operation.

[dhalbert]

Simple test, on Metro M0 with a 3492 breakout. But you don't actually have a microphone connected to get the hang.

import audiobusio
import time
import board
import array

# Our microphone
mic = audiobusio.PDMIn(board.D1, board.D9, sample_rate=16000, bit_depth = 16)
samples = array.array('H', [0] * 200)

i = 0
while True:
    i += 1
    num_recorded = mic.record(samples, len(samples))
    print(i, num_recorded)

To provoke a hang, do something some filesystem operation that writes CIRCUITPY.

[dhalbert]

The symptom is that the loop around common-hal/audiobusio/PDMIn.c:397 (MICROPY_VM_HOOK_LOOP) never exits.

In the older 2.x code, this line is in start_dma():

    I2S->DATA[1].reg = I2S->DATA[1].reg;

Writing the register provokes the transfer to start, according to the datasheet.
If I add a similar line around the // Record line in PDMIn.c, but with the subscripts changed to [0], then I get a worse crash: I get a hard fault in the MSC code, and the ASF4 device structs for MSC look like they've been overwritten.

So I'm thinking maybe there's some buffer overflow going on somewhere, and it can manifest in different ways.

[dhalbert]

I tried essentially the same program on a Trinket M0 to rule SPI flash presence as a factor in or out. Had to hack things up a bit to provide I2S on a Trinket, but I get same kinds of hangs (not examined in gdb). Not clear if coincident with filesystem operations: sometimes seems synchronized, and sometimes operation does not provoke a hang. Often hangs by itself (more quickly than on Metro M0).

[dhalbert]

I commented out escaping to the VM while filling the buffer, hoping that one of the background routines might be the issue. But I get the same kinds of hangs still ☹️

        while (!event_interrupt_active(event_channel)) {
            #ifdef MICROPY_VM_HOOK_LOOP
            // COMMENTED OUT                MICROPY_VM_HOOK_LOOP
            #endif
        }

[dhalbert]

In addition to removing the MICROPY_VM_HOOK_LOOP, as described in the previous comment. I wrapped the entire insides of common_hal_audiobusio_pdmin_record_to_buffer() in disable/enable interrupts, so it would be completely synchronous, and it still hangs the same way. When a hang happens, the first word of first_buffer contains good data, but the rest has not been filled in. So only one word was transferred.

Also checked settings of I2S peripheral. The settings are the same when a good transfer is happening as when as hang has happened.