Wrong timeout period (sometimes) in _lwevent_wait_ticks (MQX4.0)

cancel
Showing results for 
Search instead for 
Did you mean: 

Wrong timeout period (sometimes) in _lwevent_wait_ticks (MQX4.0)

Jump to solution
514 Views
antonio66
Contributor III

Hello,

I'm using a code like this with K60N512  MQX 4.0.0 and some times i have a time out after some undred of millisecond (random value).

Somebody have an explanation ?

#define BSP_ALARM_FREQUENCY  (1000)

result =_lwevent_wait_ticks(&buflwevent,LW_READBUF2,TRUE,2000); 

if(result == MQX_OK)   

{

...

thankyou

Antonio

1 Solution
175 Views
antonio66
Contributor III

Hi,

I tested whith the two function _time_get_elapsed_ticks() before the instruction

result =_lwevent_wait_ticks(&buflwevent,LW_READBUF2,TRUE,2000);

and with the same function after timeout.

The answer was corret: 2000 ticks different between the two reading...

I found the bug. My bug in the initialization of the serial ISR.

Isr_InitIsr(INT_UART3_RX_TX, Uart_RxTx3_Isr);      //OK!

NVICICPR1 |= (1<<19);   //NOT MQX ISR initialization!

NVICISER1 |= (1<<19);  //NOT MQX ISR initialization!

NVICIP51 = 0x30;   //NOT MQX ISR initialization!

_bsp_int_init(INT_UART3_RX_TX, 3, 0, TRUE);  //Correct MQX initializaion...  problem solved.

Thank you

Antonio

View solution in original post

4 Replies
175 Views
DavidS
NXP Employee
NXP Employee

Hi Antonio,

In addition to Martin's question have you re-compiled the RTOS after making the BSP_ALARM_FREQUENCY (1000)?

You can also implement the following code to check your _lwevent_wait_ticks() call with following from the MQXRM.pdf in MQX4.0\doc\mqx path:

ScreenHunter_39 Oct. 31 09.50.gif

Regards,

David

175 Views
antonio66
Contributor III

Hi David,

Yes i have re-compiled all the libraries of the MQX after making the BSP_ALARM_FREQUENCY (1000).

Hi, Martin, I mesured the time using a watch testing the right time on o modified

instruction like this:

"result =_lwevent_wait_ticks(&buflwevent,LW_READBUF2,TRUE,20000);  "   //20 second time test

if(result == MQX_OK) 

...

..  the time is right (plus or minus some tens of milliseconds  ...my reaction time on watch...)

Also i mesured the time  with an oscilloscope between string out on my serialRs485 and the complete answer of the slave (this event set the "LW_READBUF2")

and verified with a breakpoint on the IAR 6.70.

I will mesure the ticks with your suggestion.

Thankyou

Antonio

0 Kudos
175 Views
BielikM
Contributor III

Hi,

Can you explain to me how you measured the time? Test for this functionality has been added in 4.0.2 release and works. Can you try to measure ticks (with function _time_get_elapsed_ticks()) before and after _lwevent_wait_ticks function and call _time_diff_ticks()?

We should decide if it is problem of lwevent or mqx timing.

Regards,

Martin Bielik

176 Views
antonio66
Contributor III

Hi,

I tested whith the two function _time_get_elapsed_ticks() before the instruction

result =_lwevent_wait_ticks(&buflwevent,LW_READBUF2,TRUE,2000);

and with the same function after timeout.

The answer was corret: 2000 ticks different between the two reading...

I found the bug. My bug in the initialization of the serial ISR.

Isr_InitIsr(INT_UART3_RX_TX, Uart_RxTx3_Isr);      //OK!

NVICICPR1 |= (1<<19);   //NOT MQX ISR initialization!

NVICISER1 |= (1<<19);  //NOT MQX ISR initialization!

NVICIP51 = 0x30;   //NOT MQX ISR initialization!

_bsp_int_init(INT_UART3_RX_TX, 3, 0, TRUE);  //Correct MQX initializaion...  problem solved.

Thank you

Antonio

View solution in original post