![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
DemaF98
Joined: 05 May 2021 Posts: 3
|
Problem with interrupts disabled to prevent re-entrancy |
Posted: Wed May 05, 2021 4:26 am |
|
|
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 |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Wed May 05, 2021 6:09 am |
|
|
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'. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Wed May 05, 2021 6:26 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
DemaF98
Joined: 05 May 2021 Posts: 3
|
|
Posted: Wed May 05, 2021 6:54 am |
|
|
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. |
|
![](templates/subSilver/images/spacer.gif) |
DemaF98
Joined: 05 May 2021 Posts: 3
|
|
Posted: Wed May 05, 2021 7:02 am |
|
|
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? |
|
![](templates/subSilver/images/spacer.gif) |
dluu13
Joined: 28 Sep 2018 Posts: 395 Location: Toronto, ON
|
|
Posted: Wed May 05, 2021 7:25 am |
|
|
I also noticed you have divisions in your ISR.
This has caused problems in my ISRs before so just be careful. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Wed May 05, 2021 7:34 am |
|
|
His should be OK. If you look they are values that can be precalculated
at compile time by the compiler. ![Very Happy](images/smiles/icon_biggrin.gif) |
|
![](templates/subSilver/images/spacer.gif) |
|
|
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
|