https://devzone.nordicsemi.com/f/nordic-q-a/120935/thread-schedulingI have a timer int callback like this: void pwm_all_handler ( nrf_timer_event_t event_type , void * p_context ) { if ( event_type == NRF_TIMER_EVENT_COMPARE0) { pwm_gpio_trigger ( TRIGGER_TYPE_ALL ); k_event_post ( &amp; camera_event , CAMERA_TS_EVENTen-USTelligent Community 13Fri, 25 Apr 2025 02:25:05 GMThttps://devzone.nordicsemi.com/thread/532928?ContentTypeID=1Fri, 25 Apr 2025 02:25:05 GMT137ad170-7792-4731-bb38-c0d22fbe4515:e90eb734-81ec-4ff3-bc73-495120ea1e0fhanks.liu<p>Thanks,Hung.<br />Due to confidentiality reasons, I am currently unable to provide test code and need to remove the confidential parts. But I can explain the new situation, which is that once the value of K_FOREVER is changed to K_USEC (100), this blocking problem will no longer occur</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/532811?ContentTypeID=1Thu, 24 Apr 2025 11:47:46 GMT137ad170-7792-4731-bb38-c0d22fbe4515:16e44138-d6ab-4f12-bc52-6beda3c63aa4Hung Bui<p>Hi Hank,&nbsp;</p> <p>Could&nbsp; you please provide the full test code ?&nbsp;<br />Please be aware that hardware interrupt has higher priority than any thread regardless of the priority.&nbsp;<br /><a href="https://docs.zephyrproject.org/latest/kernel/services/interrupts.html">https://docs.zephyrproject.org/latest/kernel/services/interrupts.html</a><br /><br />I would also suggest to use LED(s) toggling to monitor the thread execution it&#39;s more reliable than using LOG.&nbsp;</p><div style="clear:both;"></div>https://devzone.nordicsemi.com/thread/532701?ContentTypeID=1Thu, 24 Apr 2025 03:37:42 GMT137ad170-7792-4731-bb38-c0d22fbe4515:52db732c-bab7-42a0-a230-9fdb92d3d217hanks.liu<p>And，If no log is added, the thread can only receive one event</p><div style="clear:both;"></div>