Two OSAL timers running simultaneously with POWER_SAVING enabled

Hi Stas,

Stas Omelnitskiy said:

it executes event almost immediately

What is the time of this "almost immediate" execution?

Hi Igor, thanks for reply.

Approximately 0.5 ms.

Stas.

Is it possible for you to attach the whole ISR?

I'm using the standard code from TIMAC sample application "MSA".

Interrupts handles in "hal_key.c" and there is no my changes there.

It is standard debounce timer starting and it works fine when device sleep is not enabled.

The problem is in 2 OSAL timers running simultaneously and device sleep enabled.

I guess that may be it in osal_pwrmgr_powerconserve() or halSleep() functions, may be.

This is seems to be a timer problem if it executes event not in time.

I'll have a look and try to reproduce this behavior later today when I'm back home.

Thank you, I'm grateful to you for your help.

Hi,

Try to do the following:

Instead of osal_start_reload_timer(MSA_TaskId, MSA_DELAY_EVENT, 10000);

Schedule the MSA_DELAY_EVENTonly once with osal_set_evet(), then inside the

MSA_DELAY_EVENT halt timer execution and call for a new timer to be started, like this:

 osal_stop_timerEx(MSA_TaskId, MSA_DELAY_EVENT);

 osal_start_timerEx(MSA_TaskId, MSA_DELAY_EVENT, 10000);

Ok, thank you for this advice!

I will try this tomorrow and tell about results then.

Stas.

I've tried this solution and there was no success.

My periodic (10 sec) timer is working right and 25 msec key debounce timer working wrong (executing event not in time), as it was before.

So, nothing changed :(

Stas.

Hi,

Are you experiencing the same behavior when Hal_KeyIntEnable = FALSE?

No, it works OK - in case of Hal_KeyIntEnable = FALSE, it goes in polling mode:

if (!Hal_KeyIntEnable)
{
osal_start_timerEx( Hal_TaskID, HAL_KEY_EVENT, 100);
}

and i can see using oscilloscope that HAL_KEY_EVENT executes every 100 ms and periodic timer works OK and device is sleeps between each key polling (i'm also see this with oscilloscope).

But i don't need polling mode in my application. I need interrupt mode with 100% working debounce timer :)

So if this 2 timers (100 ms polling and 10 sec periodic) is works while sleep with Hal_KeyIntEnable = FALSE, but when Hal_KeyIntEnable = TRUE, 25 debounce timer is not working - i can see one big difference between this scenarios. This is where timer is started.

100 ms polling timer is started in regular code, but 25 ms debounce timer is starting in ISR.

May this is where problem is, what do you think?

Best regards,

Stas.

Hi,

I see, but this should be working out-of-the-box, moreover, I'm familiar with OSAL from Z-stack

and BLE stack (should be the same operation system abstraction layer as in TI-MAC) and I have

never experienced behavior like described by you. I have tried to add one more event in MSA + set

the keys to be activated on interrupt (not polling), but I have no oscope at my home, so I'm not really

sure if all is ok, or not.

I'll try to think about something else, meanwhile try one more thing, disable the optimization in compiler.

Hi,

compiler optimization disabling haven't changed situation.

Yes, you are right, without oscope it is hard to understand if it
works in right way. I mean that even without debounce period key press
is detected. But i need this 100% working for absolute confidence, because i will need this for impulse counting, not for buttons.

I've descovered that when i remove this interrupt flags reset code
from "hal_key.c":

/*
Clear the CPU interrupt flag for Port_2
PxIFG has to be cleared before PxIF
*/
HAL_KEY_SW_6_PXIFG = 0;
HAL_KEY_CPU_PORT_2_IF = 0;

and put this 2 lines in HAL_KEY_EVENT handler (Hal_ProcessEvent
function in file "hal_drivers.c"), it starts to work but debounce time
is about 50 ms.

If i change HAL_KEY_DEBOUNCE_VALUE to 5 ms or 50 ms, it is not any change in debounce time.

So if i exclude interrupt flags reset from ISR (i understand that this is strange) timer is starting to work somehow, but not as needed.

I've found workaround for this problem!!!

I've added new event (HAL_KEY_DEBOUNCE_EVENT) to Hal_ProcessEvent function:

if (events & HAL_KEY_DEBOUNCE_EVENT)
{
osal_start_timerEx (Hal_TaskID, HAL_KEY_EVENT, HAL_KEY_BUSY_EVENT);
return events ^ HAL_KEY_BUSY_EVENT;
}

And in key ISR (halProcessKeyInterrupt function), i've changed direct debounce timer starting to scheduling of this event:

if (valid)
{
osal_set_event(Hal_TaskID, HAL_KEY_BUSY_EVENT);
// osal_start_timerEx (Hal_TaskID, HAL_KEY_EVENT, HAL_KEY_DEBOUNCE_VALUE);
}

So now timer is starting from regular code, not from ISR.

And it's works!!!

I have not find a reason of this issue, but it is some problems with timer starting from this ISR.

Igor, thank you, for your help!

Best regards! 

Hi Stas,

I'm glad to hear you have found a workaround, and it's working, though I'm not happy at all

with the behavior you have experienced before the workaround, it means that there is a bug

in OSAL, which can cause much bigger problems later.

Once I have the time, I simply must to investigate it further.

Previously I forgot to ask you about the setup. I know that you are trying this on CC2530,

however you didn't mention if this is a CC2530EM on top of smartRF05EB, and the error

occurs while all this powered up from USB? Have you tried to measure the timing when

the smartRF05EB (I'm assuming that you are using smartRF05EB+CC2530EM after all)

is powered from two AA batteries? Is it still happens, without the workaround?

Hi Igor,

i'm using pretty strange setup.

We've bought CC2530EMK and CC2530ZDK-ZNP kits, but no smartRF05EB board. Instead of this we are using MSP-EXP430FR5739 - it have suitable connectors for CC2530EMK boards (i can power and program it with CC Debugger with some upgrade). In some case we are using CC2530EMK stand alone. I'm understand that this setup is strange and unusual but i have to use it now :)

While debugging, I've tried code with all of this boards and with all power configuration: USB and batteries. There was no difference between boards or power configurations - this problem was at all of them.

But this is does not matters, this problem can be easily noticed on normal ( smartRF05EB+CC2530EM setup), i guess.

Stas.

A big thank you to the E2E community.

I have been struggling with some CC2541 code based on BLE 1.4.0. The code worked fine except when a key was pressed in a small window of about 2s before a timer in another task expired. Fortunately I came across the change suggested by Stas which moves the setting of the key debounce timer outside of the ISR and everything now works. This suggests to me that there is something in the timer that is not interrupt safe.

I am using Power Save and OSAL_Timers.c Revision: 32329

Bill