Interrupts / FreeRTOS on standard SDK

Technical Support
1

Hi.
I’m running an app that uses some high priority interrupts (I2C slave, and external GPIO interrupt)
I’m finding that sometimes the interrupts get missed. The interrupt doesn’t fire for the event.

Usually FreeRTOS critical sections on Cortex M3 are done by configuring interrupt base priority to configMAX_SYSCALL_INTERRUPT_PRIORITY.
This leaves higher priority interrupts (that don’t use FreeRTOS) to still execute.

I can see the Ameba SDK uses this:
portDISABLE_INTERRUPTS() __asm volatile ( " cpsid i " ::: “memory” )
portENABLE_INTERRUPTS() __asm volatile ( " cpsie i " ::: “memory” )

This looks to be a global interrupt disable?
So what happens if another interrupt fires during a FreeRTOS critical section?
Is it queued to run afterwards, or is it missed?
Thanks.

2

Hi @Smythbuilt

Please let us know what board/IC you are using, and the version of the SDK so we can understand the context better.

For Ameba IoT solutions, we manage interrupt with NVIC, to register and enable interrupt is not enough, you have to set the interrupt mask to enable each individual interrupt bit so they can trigger once the event occurs, an example of this is to look at this line,

Note that, even before this step, interrupt has already been registered and enabled at

Long story short-- it disables all interrupts including systick and pendsv so that even FreeRTOS can NOT switch task during execution of your Interrupt Service Routine, other interrupt also can not trigger

Hope I have answerd your questions and look forward to your replies~

3

Thanks for the response.
I’m using the BW16 module, and Standard SDK V6.2.

I have configured an I2C slave interface using:
InterruptRegister((IRQ_FUN)I2CISRHandle, I2C0_IRQ_LP, (u32)(obj), 3);
InterruptEn(I2C0_IRQ_LP, 3);
I2C_INTConfig(i2cslave.I2Cint.I2Cx, (BIT_IC_INTR_MASK_M_ADDR_1_MATCH | BIT_IC_INTR_MASK_M_STOP_DET | BIT_IC_INTR_MASK_M_RX_FULL | BIT_IC_INTR_MASK_M_RX_OVER | BIT_IC_INTR_MASK_M_RX_UNDER | BIT_IC_INTR_MASK_M_RD_REQ | BIT_IC_INTR_MASK_M_RX_DONE), ENABLE);

It works well most of the time, but in some cases I do a Write from the host, and the Slave device (BW13) does not appear to receive it.

With the external GPIO interrupt:
GPIO_INTMode(ARBITER_REQUEST, ENABLE, GPIO_INT_Trigger_BOTHEDGE, GPIO_INT_POLARITY_ACTIVE_LOW | GPIO_INT_POLARITY_ACTIVE_HIGH, GPIO_INT_DEBOUNCE_DISABLE);

InterruptRegister(GPIO_INTHandler, GPIOA_IRQ, (u32)GPIOA_BASE, GPIO_INTERRUPT_PRIORITY);
InterruptEn(GPIOA_IRQ, GPIO_INTERRUPT_PRIORITY);

GPIO_UserRegIrq(ARBITER_REQUEST, (void *)arbiter_irq_handler, &GPIO_InitStruct);
GPIO_INTConfig(ARBITER_REQUEST, ENABLE);

Similarly, it works fine most of the time, but in some cases the interrupt does not fire when the GPIO changes state. I had to add some code to also poll the pin to see if it changed state without the interrupt firing.

I am only guessing about the FreeRTOS interrupt disable causing this.
What else could cause interrupts to not fire when the event occurs?
Thanks.

4

Hi @Smythbuilt

As discussed eariler, calling taskENTER_CRITICAL() will disable ALL interrupt including I2C’s (at least for the case of V6.2 SDK), so it’s up to your program to speed up the processing after calling taskENTER_CRITICAL() so that it won’t miss important interrupt.

From what I can see here, there are 2 solutions,

  1. You may change the included FreeRTOS port to enable taskENTER_CRITICAL() only disable interrupt up to an user-defined priority level, see here for more details

  2. If your program have to process a lot of data in critical sections, then do not rely on the time-critical interrupt such as BIT_IC_INTR_MASK_M_STOP_DET , instead, you can query the I2C status register for RX/TX FIFO status, for example,

5

Thanks.
I don’t do anything in critical sections in my app. FreeRTOS itself calls it at times though (vPortEnterCritical) which I have no control over.

I will look solution 1 (same solution that ST Micro use.)
Thanks for the help.

6

Then it’s very strange.

Could you elaborate on how you found FreeRTOS critical section to be the cuase of this issue? bcos from what I know, FreeRTOS uses SysTick and PendSV to schedule tasks, and only if you are manuplating data shared across task, then will FreeRTOS enter critical section( e.g. send queue, semaphore, mutex etc.) to protect those global scope data

If you program never uses queue/sema then it should not enter critical section that often…

7

I don’t know for sure that FreeRTOS critical section is the cause. It’s just a theory.
Maybe I should say, FreeRTOS disabling the interrupts.

In the current Ameba port the interrupts are disabled for every task context switch:
select_next_task:
cpsid i
bl vTaskSwitchContext
cpsie i

Also, portDISABLE_INTERRUPTS() is called at various times during FreeRTOS operation.
E.g. xQueueIsQueueFullFromISR(), prvCheckPendingReadyList()

I tried to port over the IAR Cortex M33 port from FreeRTOS:

For “disabling” interrupts, this port uses ulSetInterruptMask to change the basepri register, leaving higher priority interrupts able to run still.

I got it to compile but so far it crashes on boot.

8

I dont know about IAR, but the Github v6.2 SDK is based on GCC +GNU make, so I would strongly suggest that you start looking from there,

Some of the register address will be different, so you have to really PORT the generic FreeRTOS implementation to the SDK you are using

9

I’m using IAR Embeded Workbench myself, which is why I picked that one.
I’ll spend some more time on this next week.

10

FreeRTOS 10.3.1 is the version that changed the M33 ports from disabling all interrupts, to just masking and letting high priority interrupts fire.

I’ve tried these approaches:

  • change just the port.c/portasm.s changes for portENABLE_INTERRUPTS/portDISABLE_INTERRUPTS to Ameba

  • use the generic M33 NTZ port on Ameba

  • use the entire FreeRTOS 10.3.1 code on Ameba

In all cases, it ends up the same way. Not actually crashed, but it seems to get stuck looping in vPortSuppressTicksAndSleep(). None of my tasks execute at all, so my app doesn’t boot fully.

I’m not super familiar with the porting side, so I’m stuck.
Not having responsive interrupts is going to cause me future problems on the next few apps that I need to do.

Is there anyone who can help? It seems like something that would benefit everyone.

1 Like
11

Hi, up to now, the standard SDK only supports up to FreeRTOS v10.2.0.

As RTOS is one of the most critical part of the software, changing it without testing and making sure its stable is not a good idea. However, newer version FreeRTOS might be added in the future.

For now, we have both established that

  • The I2C on BW16 has to be configured as a slave receiving device in your applicaiton and the FreeRTOS scheduler is the cause of your data-lost issue
  • Standard SDK only supports up to FreeRTOS v10.2.0

What I suggest here are,

12

Thanks for the suggestions.
I don’t think I can use method 1, as some of my registers are an odd number of bytes.
I tried method 3 to change from 1 msec tick to 2 and 4 msec. I didn’t appear to improve, and causes me some other application issues.

I added code to the I2C master host to read back the register written, and retry writing until that passes. Somehow this also didn’t help, which makes me think its some other issue.
I will investigate further.

1 Like
13

I’m working on another 2 applications now, which also appear to be impacted heavily by the global disabling of interrupts.
I need to have a timer interrupt fire accurately every 92 usec. I’m using timer 4, and usually its accurate, but in some cases the timing stretches out to 125, 137, or even as high as 180 usec.
This results in sampling errors in my code and stops the system from functioning as expected.

The same sampling routine has been used successfully for about 15 years across various other microcontrollers (STM32, Pic18, Pic24, Pic32, nRF52840) with/without an RTOS.

I’ve tried lowering the FreeRTOS tick rate, and it gives a small improvement, but the sampled signal is up to 20 msec long and I can’t run the tick rate that low without the rest of the app breaking.

Has there been any more thoughts about migrating to FreeRTOS 10.3?

Right now I’m pretty much stuck and unable to progress to getting the product to market.
Thanks.

14

I wrote some code to drive an output high when vPortEnterCritical() is called and low when vPortExitCritical() is called.
Note I am not calling these from application code, so its only from FreeRTOS itself or the SDK.

It shows that the interrupts are disabled a lot. E.g. for a period of 4 msec, it was being disabled for about 86 usec and enabled for 2 usec, repeatedly (86 disabled, 2 enabled, 86 disabled etc for a total of 4 msec.)

There are periods of about 1 msec where it is not disabled, but not any longer.
It seems pretty clear to me that this is the cause of my issues.

15

I have been trying again to change the FreeRTOS port.
Comparing the RTL8721 port with the standard M33 port, its basically the same.

I ported over the minimum code from FreeRTOS 10.3 port, to use configMAX_SYSCALL_INTERRUPT_PRIORITY set to the basepri register instead of global irq disable.

The app runs, but gets stuck at boot.
I call wifi_on() in my main thread, which gets stuck when it calls rltk_wlan_start().
This function never returns.

FreeRTOS is still running itself, processing the tick counter, but xNextTaskUnblockTime is 0xFFFFFFFF so it never attempts to swap to the next task.

rltk_wlan_start() seems to be closed source, so I can’t see why its hanging. The assembly code seems to show it gets as far as “netdev_open”

16

I must apologize here. I misdiagnosed this second issue.

The issue was not caused by interrupt disable, but was instead noise getting onto the sampled signal from a debug cable that was connected to the PCB.