[STM32] Interrupts in cmodules do not preempt the main loop

[Meekdai]

I wrote a cmodules code with stm32f405rgt6 and compiled it successfully. The function of this cmodules code is to switch the level state of GPIO regularly.

The following is the timer initialization code

void tim2_init(void)
{
  TIM_HandleTypeDef TIM2_Handle;
  __HAL_RCC_TIM2_CLK_ENABLE();

  // set up and enable interrupt
  NVIC_SetPriority(TIM2_IRQn, NVIC_EncodePriority(NVIC_PRIORITYGROUP_0, 0, 0));
  HAL_NVIC_EnableIRQ(TIM2_IRQn);

  // PWM clock configuration
  TIM2_Handle.Instance = TIM2;
  TIM2_Handle.Init.Period = 65535;
  TIM2_Handle.Init.Prescaler = 0;
  TIM2_Handle.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
  TIM2_Handle.Init.CounterMode = TIM_COUNTERMODE_UP;

  HAL_TIM_PWM_Init(&TIM2_Handle);
}

void tim3_init(void)
{
  TIM_HandleTypeDef TIM3_Handle;
  __HAL_RCC_TIM3_CLK_ENABLE();

  // set up and enable interrupt
  NVIC_SetPriority(TIM3_IRQn, NVIC_EncodePriority(NVIC_PRIORITYGROUP_0, 0, 1));
  HAL_NVIC_EnableIRQ(TIM3_IRQn);

  // PWM clock configuration
  TIM3_Handle.Instance = TIM3;
  TIM3_Handle.Init.Period = 65535;
  TIM3_Handle.Init.Prescaler = 0;
  TIM3_Handle.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;
  TIM3_Handle.Init.CounterMode = TIM_COUNTERMODE_UP;

  HAL_TIM_PWM_Init(&TIM3_Handle);

}

After successfully programming the compiled firmware, I successfully saw the GPIO switching. But when I wrote other code in the micropython main loop, I found that the GPIO switching was different. It felt like the timer interrupt did not preempt the main loop.

Whether the interrupt in micropython cannot be preempted?

[andrewleech]

If you're using the timer in PWM mode to directly drive the pin, you can do this directly in micropython without using C for timer config

PWM_PIN = Pin("A10", Pin.OUT)
PWM_TIMER = Timer(1, freq=1_000_000)
PWM_TIMER_CH = PWM_TIMER.channel(3, Timer.PWM, pin=PWM_PIN, pulse_width_percent=0)

If you are only flipping a pin from the timers you should use the directly managed timer channel because then there's no interrupt actually involved, it's all in hardware.

Or are you firing off a Timer interrupt that runs other code, not just pin on/off ?

There is a heirachy to the interrupts, ones with a lower number can / do pre-empt lower number ones in progress:

micropython/ports/stm32/irq.h

Line 134 in 64c79a5

#define IRQ_PRI_SYSTICK NVIC_EncodePriority(NVIC_PRIORITYGROUP_4, 0, 0)

So it will depend on what code is running in main whether it's doing something that can preempt timer interrupts - looking at that list the obvious one is probably flash.... or lots of uart / usb traffic ?

Considering you're already coding in C land, you can change the IRQ prio on the timer interrupt enable commands, but keep in mind that you might cause issues in the other interrupts if your timer one runs too long. Also if you're writing to internal flash, that completely blocks CPU while in progress so all interrutps get paused.

[andrewleech]

That might be DMA interrupts being used by the SPI communication to W5500.

If you can use the timer.pwm channel to direct drive the gpio without using an interrupt it'll be perfectly stable. Or changing interrupt priorities might be fine too.

[Meekdai]

The priority of DMA is 5. I changed the priority of TIM2 to 3, but it still doesn’t work.

#define IRQ_PRI_DMA             NVIC_EncodePriority(NVIC_PRIORITYGROUP_4, 5, 0)

NVIC_SetPriority(TIM2_IRQn, NVIC_EncodePriority(NVIC_PRIORITYGROUP_0, 0, 0));

Is it possible that some code in the W5500 disables all interrupts

[Meekdai]

I found in spi_wait_dma_finished:
https://github.com/micropython/micropython/blob/64c79a54239d700ecb8d7f07b13388dc79f28993/ports/stm32/spi.c#L551C29-L551C29

Is there a way to not disable interrupts?

[andrewleech]

That's curious, I'm not really sure why it's needing to disable interrupts like that.... however I'd expect the wfi / re-enable should really kick in for the timer interrupt as well anyway and work without any particular delay to timer interrupt.
It'd be worth a test with the irq disable/enable lines commented out to just see what happens.

[Meekdai]

After commenting these lines, the motor runs smoothly and W5500 communication is also normal.

[andrewleech]

git blame on those lines comes up with c0496fd

Which is interesting reading... but I guess even if the wfi behaves as written I can see it adding some delay / latency as it runs the commands there to exit wfi and re-enable interrupts before the timer interrupt fires off.

Do you know how much delay you're getting on the interrupt? is it like just a bit of jitter (from say these couple of commands running) or is it heaps late / missing interrupts altogether?

[Meekdai]

The timer interrupts takes very little time, it runs code like below

void HandleStepResetIT()
{
  GPIO_Write(STEP_GPIO_Port, (GPIO_ReadOutputData(STEP_GPIO_Port) & ~STEP_MASK) | (step_port_invert_mask & STEP_MASK));
}

[andrewleech]

I was meaning whether you can tell how much the interrupt is delayed by rather than how long it takes to run, trying to figure out if that spi code is causing timer interrupts to be missed or just a fraction late. Probably no way to know unless you can inspect those step output pins with an oscilloscope to see how "late" the pin changes are.

Out of interest, are you using that interrupt to set the gpio levels of multiple pins at the same time?

[andrewleech]

I tried to reproduce this in pure python

import pyb

pin = pyb.Pin("B12", pyb.Pin.OUT)
def cb(_):
    pin.on()
    pin.off()

tim = pyb.Timer(4)
tim.init(freq=25_000)

spi = pyb.SPI(1, pyb.SPI.CONTROLLER, baudrate=600000, polarity=1, phase=0)

b = "\xA5"*20000

def do_spi():
    for _ in range(10): spi.write(b)

tim.callback(cb)

On stm32F411, wIth python callback I couldn't get faster than ~35Khz timer before the interrupt was using 100% cpu. But with that code I had a pulse stream that when I ran the spi function I'd get some interruptions of ~80uS
Howver, I then commented out all the interrupt stuff in the spi function so it's like:

STATIC HAL_StatusTypeDef spi_wait_dma_finished(const spi_t *spi, uint32_t t_start, uint32_t timeout) {
    volatile HAL_SPI_StateTypeDef *state = &spi->spi->State;
    for (;;) {
        if (*state == HAL_SPI_STATE_READY) {
            return HAL_OK;
        }
        if (HAL_GetTick() - t_start >= timeout) {
            return HAL_TIMEOUT;
        }
    }
    return HAL_OK;
}

But the same 80uS interruptions occurred, no change at all. So I'm not sure where the issue is; perhaps it's an irq priority issue on my end, but even then I'm not seeing the 200uS interruptions you're getting.

[Meekdai]

W5500 also has the following functions, which I also commented

https://github.com/micropython/micropython/blob/06a7bf967c58644a0d341764994bdcc9253b4527/extmod/network_wiznet5k.c#L125C1-L131

#if defined(GRBL)
STATIC void wiz_cris_enter(void) {
}

STATIC void wiz_cris_exit(void) {
}
#else
STATIC void wiz_cris_enter(void) {
    wiznet5k_obj.cris_state = MICROPY_BEGIN_ATOMIC_SECTION();
}

STATIC void wiz_cris_exit(void) {
    MICROPY_END_ATOMIC_SECTION(wiznet5k_obj.cris_state);
}
#endif