Are interrupts ever disabled by WICED?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
cogoc_1937206
Level 4
Level 4
First like received

Hello,

I'm trying to setup some higher-frequency data capture (~8ms period) on a STM32F2XX-based WICED module.  This seems to work fine 99.5% of the time, but on average I seem to be missing 0.5% of the interrupts I expect to be processing.  I've setup a scope to monitor this and it looks like most if not all of the losses come from a spurious event that seems to happen every 5-30 seconds.  This event lasts either ~100ms or ~240ms and prevents the interrupt request from being processed.  Interestingly, when the event is ~100ms in length, the ISR appears to run (my trace GPIO gets asserted), but the event being posted to a high-priority worker thread to do the processing is not run (GPIO not released for the full ~100ms).  When the event is ~240ms in length, the ISR doesn't appear to run at all (GPIO never asserted).

A bit more detail on the setup:  This is using ThreadX/NetX-Duo.  I've created a high-priority worker thread for doing the data collection work (runs at priority-level 0) and dropped the WWD thread and system monitor threads to priority level 1.  I've also applied the ThreadX patch that was posted in a blog entry to allow preemption of lower priority threads.

Any hints guidance as to what might be causing this would be greatly appreciated!  Cheers!

0 Likes
9 Replies
cogoc_1937206
Level 4
Level 4
First like received

(Forgot to mention that we're running on WICED 3.1.2.)

0 Likes

Interestingly, today the ~100ms blocks where the interrupt fires but the worker thread doesn't run seem to have gone away.  Now I'm only seeing two ~230ms blockages happening within a span of ~540ms every 60 seconds.  The 60 second periodicity seems to be quite repeatable and accurate, so I wonder if this could have something to do with a sleep behaviour of WICED?

Again, any suggestions would be greatly appreciated.

0 Likes
Anonymous
Not applicable

Are you using ThreadX ? Did you apply this patch:  ThreadX Patch for WICED SDK-3.1.x ?

without this patch, a low priority task can prevent a high priority task to run, long enough for you to miss your events.

0 Likes

Hey gbrivet,

Thanks for the response!  Yes, I am using ThreadX, and yes I have applied the patch.  Unfortunately, this seems to be caused by something else....

Cheers!

0 Likes

Hi,

Could you try disabling the MCU power save by defining the WICED_DISABLE_MCU_POWERSAVE in your application?

Seyhan

0 Likes

Hey Seyhan,

I haven't tried enabling WICED_DISABLE_MCU_POWERSAVE with our higher frequency interrupts to see if it overcomes the misses, however I did go back and confirm that WICED_DISABLE_MCU_POWERSAVE by itself does not work reliably.  (See Disabling MCU power save and AMPDU)  As mentioned in that thread, I've found that this problem exists for the BCM943362WCD4 dev board -- when power cycling the board (i.e. disconnecting and reconnecting the USB cable) the radio fails to initialize properly and will not join a network.  Once triggered, this will persist across any reset cause until the board has been reprogrammed.  I should also mention that I'm using WICED 3.1.2 now, building the snip.apsta application with the default RTOS and IP stack (ThreadX/NetXDuo).

I'll report back once I've been able to see if the WICED_DISABLE_MCU_POWERSAVE  #define improves the interrupt handling.  Assuming it does, we'll still need a fix to ensure our boards are able to startup properly after being power cycled before we can make use of it.

Cheers!

0 Likes

Hey Seyhan,

I finally came back to this the other day and figured out what's going on -- the ~240ms block of interrupt processing is caused by DCT writes.  My understanding is that the STM32 stalls any attempt to read from its flash during a flash write or erase operation.  So interrupts aren't actually being blocked because ISRs are disabled, but because no code is able to execute.

(The fact that DCT writes were happening once per minute was an issue in and of itself; that's been fixed separately.)

I noticed that this also impacts the systick interrupt, so I've added some code to the end of DCT write operations that fudges the system clock ahead by ~240ms after each write to minimize the time drift that DCT writes are otherwise causing.

Cheers!

0 Likes

Hi,

That is a good info, I assume you were initiating the DCT update periodically and had been removed.

Do you still have data collection issue (with ~8ms period)?

Seyhan

0 Likes

Hi Seyhan,

Yes, that's right -- we had a process that was [unnecessarily] writing to the DCT periodically.  This has been fixed so that DCT writes only occur if necessary, which becomes very rarely.

Collecting data at 8ms still isn't quite perfect, but the other (smaller) issue I was seeing was only the worker thread being blocked briefly, the interrupts were still being processed.  Actually, this may have been fixed with the patch to enable preemption within ThreadX...  I can't recall if I continued to see the ~100ms blocks after making that change or not.  I'll have to hook up the scope again.

Cheers!

0 Likes