lwgpio interrupt restrictions?

[billnd]

I'm having trouble with the lwgpo and interrupts. Should I be able to use lwgpio_toggle_value() within an interrupt? If I toggle one pin in the int, and toggle a different pin in the foreground they seem to conflict. Do I really need to disable interrupts round lwgpio function calls?

There are no references made to this in either the io user guide, or the mqx ug. For the life of me I can't find a definitive list of components I can safely use in the background, is there one?

Thanks in advance

Bill

[c0170]

Hello billnd,

there shouldn't be any problem to use lwpgio inside ISR. Can you describe it more what you do, a code snippet would be appreciated.

Toggle value only writes into PTOR register inside GPIO module ( 0 - no change, 1 - the inverse of its existing logic state)

handle->gpio_ptr->PTOR = handle->pinmask;

Regards,

0xc0170

[billnd]

OK, my mistake. Its not quite what I thought, but still causing a problem. I have the PDB firing the ADC, which in turn generates a DMA, which finally generates an interrupt.

This is constantly running in the foreground to indicate the activity of the ADC...

while( true ){
     _sched_yield();
     while( ( ADC0_SC2 & ADC_SC2_ADACT_MASK ) ){
          lwgpio_set_value( &LED2, LWGPIO_VALUE_HIGH );
     }
     lwgpio_set_value( &LED2, LWGPIO_VALUE_LOW );
}

While this interrupt should just show the DMA int status.

void int_dmaX(void *pin)
{
    DMA_CINT = DMA_CINT_CINT( X );
    lwgpio_toggle_value( &LED1 );
}

What I get though is the LED1 status altering almost randomly. Its something to do with locking up the task and using lwgpio while waiting for the ADC activity to finish. If I use (next bit of code) it works as expected. It also works as expected if I remove the lwgpio call from the while loop.

while( ( ADC0_SC2 & ADC_SC2_ADACT_MASK ) ){
     _sched_yield();
     lwgpio_set_value( &LED2, LWGPIO_VALUE_HIGH );
}    

Cheers for your help so far.

[c0170]

Hello billnd,

why don't you change you approach to :

LED2_HIGH;
while(conversion_ongoing);
LED2_LOW;

By the way, lwgpio_set_value accesses PDOR register which in your case happens also in DMA ISR. Because PTOR changes PDOR register.

Regards,

0xc0170

[billnd]

Martin,

Thanks for the suggestion, but I don't really think that is getting to the heart of the problem. In fact really all that method is doing is reducing the chance of the problem, rather than curing it.

Can I just check that I've understood you correctly. You are saying that set_value and toggle_value should not be done in the foreground and the isr because they can cause this sort of unexpected result? Is this in the documentation somewhere, how do I know which functions are safe to use in ISR's? Do I really have to read every line of MQX source code and work it out for myself?

Sorry, not griping at you, just frustrated with MQX!!

[DavidS]

Hi Bill,

I don't think Martin is saying not to do it but there are many ways to skin a cat and some better than others but at end of day the solution that you like is best.

My $0.02 is you should use synchronization methods to do this rather than polling.  I'd recomment using lwevent to set flag(s) in the interrupt and clear it in the task(s).

I'm just guessing that you have other tasks in the system that must run at higher priority which mean you could miss seeing the ADC conversion active bit setting.

Another factor is how fast are you triggering a ADC sample?  Just question to better understand the situation.

I still think synchronization is the way to go to notify a task that the ADC converstion is complete.  But if you are just toggling an LED why bother having the task mess with the LED?

Regards,

David

[billnd]

David,

I agree, there are more elegant ways to to achieve the LED function. In reality, it was just a bit of hacked together code to prove to myself that the DMA was being generated at the correct intervals. Adding a whole task in, just to test that, seemed a bit long winded. I've learned my lesson now. I'll include as little as possible in the ISR routines, even my prototype ones.

I'd still like a list of MQX functions that are safe to use in INTs. The UG list some functions that should not be used, for mostly obvious reasons, perhaps there should be a list of functions that are OK to use?

Cheers for your help.

Bill

[DavidS]

Hi Bill,

Rule ot Thumb in an ISR is not to call any blocking function.

The MQXUG.pdf (C:\Freescale\Freescale_MQX_4_0\doc\mqx) Section 3.9 Handling Interrupts and Exceptions does have list of MQX function that are OK to use in Section 3.9.3.1.

Section 3.9.3.2 has a list of MQX functions not to call.

Hope this helps but your experimentation is really good.  Glad you are doing that as that is often my process to answer these questions.

Regards,

David

[billnd · Accepted solution]

Ah, just seen in section 3.9.2, it says that these functions can be used...

_event_set()

_lwsem_post()

_sem_post()

_msgq_send family

Cheers

Bill

[billnd]

David,

We must be looking at different documents. Mine is MQXUG, rev 6. 12/2012. Section 3.9.3.1 has a list of functions that the ISR "cannot" call, and 3.9.3.2 has a list that ISR's "should not" call. I can't find a list of functions that are OK to call.

3.9.3.1 Functions That the ISR Cannot Call

3.9.3.2 Functions That ISRs Should Not Call

I think you must have a more up to date document than I have access to. Just in case, I downloaded the latest MQX 4.0 from Freescale and installed it on my laptop, still comes up with the rev 6 document.

Cheers

Bill