dsPIC interrupt & queue

Kernel
#1

ruben_saz wrote on Saturday, November 17, 2007:

I’m having trouble with a interrupt that posts data in a queue. The ADC interrupt is supposed to write 2 words obtained from ADCBUF0 y ADCBUF2 on a queue for further prossesing. The problem is that this causes the device to branch to the _AddressError Trap vector. If I remove this line

xYieldRequired = xQueueSendFromISR( adcValues, &analogReading, xYieldRequired );

from the code. The program runs ok, but obviously i don’t get the ADC values on the processing task. Here is the ISR code.

void __attribute__((__interrupt__, auto_psv)) _ADCInterrupt(void)
{
    unsigned int analogReading, readCount = 0;
    portBASE_TYPE xYieldRequired = pdFALSE;

    IFS0bits.ADIF = 0;
    while( readCount < 2 )
    {
        analogReading = ReadADC12(readCount);
        xYieldRequired = xQueueSendFromISR( adcValues, &analogReading, xYieldRequired );
        readCount++;
    }
    readCount=0;
    if( xYieldRequired != pdFALSE )
    {
        taskYIELD();
    }
}

//END OF ISR CODE
------------------------------------------------

And this is the code for the processing task, in this case it only displays the integer value obtained from the ADC.

for(;;){
asm("btg LATD, #6");    // TOGGLE LED, JUST TO SEE THAT THE TASK IS RUNNING
ADCON1bits.SAMP = 1;    // START SAMPLING AND THEN AUTOMATIC CONVERSION
vTaskDelay( 1000 );     // WAIT 1 SECOND (FOR TESTING PURPOSES) ADC INTERRUPT POST DATA
                        // IN THE QUEUE WITHIN THIS PERIOD OF TIME

if(xQueueReceive( adcValues, &adcData, ( portTickType ) 10 ))
{
    v2 = adcData;
}
           
if(xQueueReceive( adcValues, &adcData, ( portTickType ) 10 ))
{
    v1 = adcData;
}
           
sprintf( cStringBuffer, "V: %d  A: %d", v1, v2 );   // Print string to buffer
xQueueSend( xLCDQueue, &xMessage, portMAX_DELAY );    // Send the message to the LCD task
}

I’m running it on a dsPIC30F6014A, and I’m using the MPLAB ICD2, Any help with this will be greatly appreciated.

Cheers!!

#2

rtel wrote on Saturday, November 17, 2007:

I cannot see anything that is obviously wrong, on the assumption that cStringBuffer[] is large enough.  It could be a stack overflow within the task.  Can you try removing the call to sprintf() because when using GCC this is likely to use a LOT of stack.  Maybe just set cStringBuffer to a const string to make sure it contains something valid ( strcpy( cStringBuffer, "test" ) ).  I know this removes the functionality of seeing the values but will be a good test.

You could try making the task stack bigger too, and ensuring there are no large variables on the stack (is cStringBuffer on the stack). 

Any of these things making a difference would indicate a stack issue.

Regards.

#3

ruben_saz wrote on Saturday, November 17, 2007:

Hi Richard!

As you said, the problem was the stack allocated to that task. It seems that it’s not good to write programs at late night, one can forget to check such trivial things :smiley:

Thank you very much.