AnsweredAssumed Answered


Question asked by Matteo Trivellato on Oct 28, 2014
Latest reply on Nov 24, 2014 by Andrei Catalin Frincu

Dear All,


I'm using MKW01 with Radio Utility source code which can be downloaded from I observed that in the provided project, UART transmission is blocking, indeed we always have the following code when sending UART data to external host.


(void)UartX_Transmit("hello world", 11, UartTxCallBack);

while (UartX_IsTxActive());


The same approach is used also when receiving a wireless packet that must be transmitted to external microcontroller. Indeed the function (void)MLMERXEnableRequest(gpSmacRxPacket, 0);


is called only after UART transmission is completed.


In my project I would like to have a non-blocking approach for UART transmission, in other words I would use a static buffer for UART TX activities where I can copy the information to be transmitted to external host and leave the UART TX ISR to handle UART TX. With this not blocking approach it would be possible to call MLMERXEnableRequest() before UART transmission is completed. Unfortunately I observed that if I call MLMERXEnableRequest() while UART TX is in progress it seams that RX enable request is not executed properly even if it does not return any error. Indeed I'm not able to receive other wireless packets. The problem is solved if I call MLMERXDisableRequest() and MLMERXEnableRequest() again.


Interestingly if I protect from UART TX ISR calls both MLMERXEnableRequest() and also Phy_ISR() when it is called for the first time when receiving a new wireless packet everything works fine. In other words RF RX packet handling is successfull if I temporary disable UART TX ISR. It seams that there are some activities in the above functions and in general in RF RX packet handling that are sensitive to interruptions or delays caused by UART TX ISR. I want to underline that UART TX ISR is the short ISR provided in the source code and it has the same priority of all other ISRs called in the project.


Does anybody know how to explain this behaviour? Should SMAC primitives and in general RF RX packet handling be protected from other application ISRs?


Best Regards,