Enabling Software Interrupts Appears to Freeze Program

[ComputerAided]

Enabling Software Interrupts Appears to Freeze Program

Using the ARM NVIC appears to freeze the apollo3 microcontroller a short while after the PDM IRQ is enabled.

My workbench

• I'm using an Artemis Blackboard ATP with version 1.0.2 of the SparkFun Apollo Library
• It is connected over a USB-C cable and is using the onboard microphone
• This is being powered over the USB port on my Laptop

Steps to reproduce

To do this, I started adapting the code from the pdm_fft example in the apollo3 evaluation board example code. In the init function, it appears the NVIC_EnableIRQ(PDM_IRQn); function call freezes the chip a short while later when the pdm_config_print(); function is called.

The following functions are called as follows:

void pdm_init(void) {
    ...
    // There appears to be an error in this IRQ Enable
    // Commenting this function apperars to solve this issue,
    // although I believe this means the code can no longer be interrupt-driven
    NVIC_EnableIRQ(PDM_IRQn);
}

void setup () {
    ...
    //
    // Turn on the PDM, set it up for our chosen recording settings, and start
    // the first DMA transaction.
    //
    pdm_init();
    pdm_config_print();
}

Expected behavior

It is expected the interrupt is enabled and the sketch will continue into the pdm_config_print() function.

Actual behavior

The pdm_config_print() function stops output about halfway through the first line it is supposed to print.

[ComputerAided]

I have put the full source code of my example code here. By changing the interrupt enable at lines 107-108, the chip will only appear to freeze serial communications when the AM_HAL_PDM_INT_OVF is added. None of the other interrupts appear to invoke this issue.

I attached a logic analyzer to the TX0/RX0 UART signals and to the pins 36/37 PDM signal pair. Regardless of whether the AM_HAL_PDM_INT_OVF is enabled, it appears the PDM hardware is outputting the expected 6MHz clock signal and that the microphone is sending data back. My guess is that this is somehow causing the ISR to be called repeatedly and a flag is not being cleared, and the sketch can never return to the pdm_config_print() function.

[nseidle]

Hi @ComputerAided - Thanks for reporting. I have replicated the issue and created a PDM branch. I agree, the code gets hung at

NVIC_EnableIRQ(PDM_IRQn);

Owen recommended we

extern "C" void am_pdm0_isr(void) {
}

To try to prevent mangling by Arduino when the ino gets turned into CPP. This didn't fix it.

It looks like the weakly defined am_pdm_isr() in startup_gcc is not getting overwritten by our am_pdm_isr. Once we enable the PDM interrupt we are getting sent to interrupt am_default_isr() instead of the correct ISR.

I'm still digging. It looks like the linker may be removing our ISR as it is 'unused'? Not sure yet.

[nseidle]

Ah! The isr is named incorrectly.

SDK v2.1.0 which our core is based on uses am_pdm_isr(). SDK v2.2.0 which is where I look at the examples uses am_pdm0_isr(). Removing the 0 correctly overwrites the weakly defined isr:

extern "C" void am_pdm_isr(void) {
}

I found this by looking at startup_gcc.c inside the Nano variant. I'll clean up my example a bit and try to make it use the variant pin defs instead of my hardcoding in a bit.

[ComputerAided]

@nseidle, glad to see you found the problem. I was looking through SDK v2.1.0 and in the examples for the apollo3 evaluation board, I saw that the PDM ISR is stilled called by am_pdm0_isr in startup_gcc.c. I think it may be a good idea to list the names of all of the ISRs in documentation somewhere, as my guess is that more people will probably want to use the ISRs for the different hardware peripherals. I'd be willing to help write a wiki for this repository.

Would it be possible for you to post a gist of the software you used to get the example to work? Even if I need to change a few pin definitions, I think it would be a good example for people to use until you can release the example version using the variant pin definitions.

[nseidle]

Good idea. Here's the gist. Please check the branch as well.

Please see the startup_gcc.c file. It contains all the current and possible ISRs as exposed through the SDK. I welcome any wiki pages you'd like to create!

[ComputerAided]

@nseidle, thanks for the gist! I'll have to try it out sometime soon.

I started the wiki and it is in pull request #39. As I said in #39, I do not know if the wiki will transfer over by a pull request, so let me know if there is a better way to transfer the wiki pages if you would like them as part of this repository.

[ComputerAided]

@nseidle we now have a wiki page for this issue here. One thing that needs to be added is that an enabled ISR that is not overwritten will default to a while (1);, which is probably what was causing the processor to freeze when it was being run. According to the BSP, "this is the code that gets called when the processor receives an unexpected interrupt. This simply enters an infinite loop, preserving the system state for examination by a debugger."

Is it okay to close this issue?