CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
Problem with interrupts disabled to prevent re-entrancy

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
DemaF98



Joined: 05 May 2021
Posts: 3

View user's profile Send private message

Problem with interrupts disabled to prevent re-entrancy
PostPosted: Wed May 05, 2021 4:26 am     Reply with quote
Hello,
I am developing an isr that is fired every time a new byte is received on my uart2 module and i keep getting this warning:
Warning#216 Interrupts disabled during call to prevent re-entrancy: (@MUL1616)

I am using a PIC18LF6722 and i am compiling with CCS C (v.5.083)

Can someone please tell me why is this warning popping up?

Here is the code of the ISR:

Code:

#INT_RDA2
        void Uart2Interrupt(void)
        {
            if (unreadRadioPacketsCounter <= (sizeof receivedRadioPacketsBuffer / sizeof receivedRadioPacketsBuffer[0]))
            {
                incomingRadioPacketBuffer[receivedRadioBytesIndex] = fgetc(UARTPORT_WL);
               
                receivedRadioBytesIndex++;

                if (receivedRadioBytesIndex == sizeof incomingRadioPacketBuffer)
                {
                    if ((incomingRadioPacketBuffer[receivedRadioBytesIndex - 1] & 0x80) == _masterCmd)
                    {
                        if (receivedRadioPacketsIndex < (sizeof receivedRadioPacketsBuffer / sizeof receivedRadioPacketsBuffer[0]))
                            receivedRadioPacketsIndex = 0;

                        for (int i = 0; i < sizeof incomingRadioPacketBuffer; i++)
                        {
                            receivedRadioPacketsBuffer[receivedRadioPacketsIndex][i] = incomingRadioPacketBuffer[i];
                            // I have noticed that if i write the previous line like this:
                            // receivedRadioPacketsBuffer[0][i] = incomingRadioPacketBuffer[i];
                            // The warning disappears so this leads me to believe the cause of this warning is either
                            // the variable receivedRadioPacketsIndex or has something to do with writing inside
                            // bidimensional arrays in an isr
                        }
                       
                        receivedRadioPacketsIndex++;
                       
                        unreadRadioPacketsCounter++;
                    }

                    receivedRadioBytesIndex = 0;
                }
            }
        }


Here is the definition contained in a .h file of the variables used inside the isr:

Code:

char incomingRadioPacketBuffer[5];
char receivedRadioPacketsBuffer[64][5];
int receivedRadioBytesIndex;
int receivedRadioPacketsIndex;
int unreadRadioPacketsCounter;


Here is the definition contained in a .h file of the settings:

Code:

    #include <18LF6722.h>

    #DEVICE ADC=10

    #fuses H4,NOWDT,NOPROTECT,NOLVP,CCP2E7,BROWNOUT,BORV27,NODEBUG

    #use delay(clock=40000000)

    #use fast_io(A)
    #use fast_io(B)
    #use fast_io(C)
    #use fast_io(D)
    #use fast_io(E)
    #use fast_io(F)
    #use fast_io(G)

    #use rs232(STREAM=UARTPORT_USB, UART1, BAUD=19200)

    #use rs232(STREAM=UARTPORT_WL, UART2, BAUD=19200)

    #use spi(STREAM=SPIPORT_1, SPI1, MODE=0, BAUD=2000000)

    #use spi(STREAM=SPIPORT_2, DI=PIN_D5, CLK=PIN_D6, MODE=3, BAUD=2000000)

    #use i2c(STREAM=I2CPORT_KB, MASTER, SCL=PIN_B3, SDA=PIN_B4)



Thanks in advance for the answers
Ttelmah



Joined: 11 Mar 2010
Posts: 19510

View user's profile Send private message

PostPosted: Wed May 05, 2021 6:09 am     Reply with quote
Yes, you have already realised what is causing it.
To calculate 'where' a byte is in the two dimensional array, it has to
multiply the index, by the size of the element. It is using the 16*16 bit
multiplication for this.
Two different solutions exist:
First alter the layout so this calculation does not have to happen. There
are other ways of laying things out that would avoid this. For instance you
could generate a pointer to the start of the array, and just add the element
size to this as you move forwards through the array. Result, no multiplication
needed.
The second is to generate a second copy of the maths library so that the
16*16bit multiplication routine used in the interrupt, is not the one used
in the main code. A search here will find how to do this.
However the pointer and increment solution is faster and smaller, so probably
the 'way to go'.
temtronic



Joined: 01 Jul 2010
Posts: 9226
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed May 05, 2021 6:26 am     Reply with quote
Additonally you have two potential problems
1) "errors' is NOT in the USE RS232( ...options....), so sooner or later, the UARTS WILL 'freeze' during reception of data...
2) I see USE FAST_IO() but no TRIS_x() statements. Unless your program is very 'time sensitive', simply let the compiler use 'standard_io', the default.
DemaF98



Joined: 05 May 2021
Posts: 3

View user's profile Send private message

PostPosted: Wed May 05, 2021 6:54 am     Reply with quote
Ttelmah wrote:
Yes, you have already realised what is causing it.
To calculate 'where' a byte is in the two dimensional array, it has to
multiply the index, by the size of the element. It is using the 16*16 bit
multiplication for this.
Two different solutions exist:
First alter the layout so this calculation does not have to happen. There
are other ways of laying things out that would avoid this. For instance you
could generate a pointer to the start of the array, and just add the element
size to this as you move forwards through the array. Result, no multiplication
needed.
The second is to generate a second copy of the maths library so that the
16*16bit multiplication routine used in the interrupt, is not the one used
in the main code. A search here will find how to do this.
However the pointer and increment solution is faster and smaller, so probably
the 'way to go'.


Thank you very much, i didn't know positions inside arrays were calculated like that, i'll use the pointers.
DemaF98



Joined: 05 May 2021
Posts: 3

View user's profile Send private message

PostPosted: Wed May 05, 2021 7:02 am     Reply with quote
temtronic wrote:
Additonally you have two potential problems
1) "errors' is NOT in the USE RS232( ...options....), so sooner or later, the UARTS WILL 'freeze' during reception of data...
2) I see USE FAST_IO() but no TRIS_x() statements. Unless your program is very 'time sensitive', simply let the compiler use 'standard_io', the default.


Thanks for the answer.

The tris definitions are in the main.c file, i forgot to post them.

As for the ERRORS key in the use rs232 statement, i've seen it in use before but i wasn't sure what it did and how it worked because in the ccs manual it is not thoroughly explained.
Do i just put it in the use rs232 statement and it will reset the uart when there's a transmission error? Is there an interrupt that fires when an error occurs? Is there a variable where i can check the current status of the uart?
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Wed May 05, 2021 7:25 am     Reply with quote
I also noticed you have divisions in your ISR.

This has caused problems in my ISRs before so just be careful.
Ttelmah



Joined: 11 Mar 2010
Posts: 19510

View user's profile Send private message

PostPosted: Wed May 05, 2021 7:34 am     Reply with quote
His should be OK. If you look they are values that can be precalculated
at compile time by the compiler. Very Happy
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group