I think that I'm seeing this issue as well. In my case, I saw that when porting from 3.3.1 to 3.5.2.
As a workaround, I used the higher frequency timer callback to invoke the lower frequency timer callback every such and such invocations.
Note that I suspect that it might be related to placing a stack pointer object (message) on the thread queue while the thread is already performing a task. Since I don't have the ThreadX code, I cannot verify that hypothesis.
Can you share the code to reproduce this issue?
I'd like to take a look.
BTW, which OS/Network stack are you using? (ThreadX or FreeRTOS?)
1 of 1 people found this helpful
I have made an application similar to the demo "temp_control". There are 2 registered timed_events:
1. wiced_rtos_register_timed_event( &post_timed_event, WICED_NETWORKING_WORKER_THREAD, &post_to_server, POST_INTERVAL, 0 );
2. wiced_rtos_register_timed_event( &sensor_timed_event, WICED_HARDWARE_IO_WORKER_THREAD, &take_sensor_reading, SAMPLE_INTERVAL, 0 );
1. Reads values from an i2c device, every 2 seconds.
2. Posts the values (wiced_http_get) to a server, every 50 seconds.
The problem is that the two events don´t work together. The application hangs in the post function.
If I comment out one of the timed events, the other will work as expected.
The functions share a variable which has a mutex.
What may be the problem here?
You might want to take a look at this issue as well. (timer related).