My program contains few global variables , whose values are set during the interrupt service routine (USCI_A0_ISR()) execution.
Once the execution of USCI_A0_ISR() is done , will the global variables hold the value assigned or will be set back to void/0.????
//Global variables
int ptr = 0;
char rxBuffer[16];
int flag = -1;
int check[2];
void __set_flag(void)
{
if (strcmp(rxBuffer,"OK") == 0) flag = 0;
else if (strcmp(rxBuffer,"CONNECT") == 0) flag = 1;
else if (strcmp(rxBuffer,"NO CARRIER") == 0) flag = 3;
else if (strcmp(rxBuffer,"ERROR") == 0) flag = 4;
}
void __GSM_client(void)
{
while (flag == -1);
if (flag == 0) check[0] = buflen(rxBuffer);
}
void main(void)
{
__Buffer_init();
__low_level_init(); //WDT
__UART0_init(); //UART
__bis_SR_register(GIE); //interrupts enabled
__delay_cycles(1000); // wait till UART intial
__GSM_client();
__no_operation(); // For debugger
}
#pragma vector=USCI_A0_VECTOR
__interrupt void USCI_A0_ISR(void)
{
char byte;
while (!(UCA0IFG&UCTXIFG));
byte= UCA0RXBUF;
UCA0TXBUF = byte;
if (byte == '\r') {
//push_char(byte);
ptr = 0;
__set_flag();
//__Buffer_init();
}
else{
push_char(byte);
}
}
Here is the code snippet of what I am doing. I am setting the "flag" based on the response obtained . When I see the register view in Code Composer Studio , the "flag" value is set correctly , but if try using the value of "flag" elsewhere the value of "flag " is not reflected.
Any pointers over concepts of the interrupt service routine or when loopholes in my coding method appreciated
Thanks in Advance
AK
Within the interrupt, you are directly or indirectly changing several global variables, e.g. ptr, flag, and I'm assuming rxBuffer[?]. They are not declared "volatile" so their value may or may not change when you return from the interrupt. This is a bug because the behavior can change based on where in the execution of the code the interrupt occurs and what the level of optimization is. As a rule of thumb, any variable modified by an interrupt routine should always be declared volatile.
If you're sure that making the shared variables volatile isn't working then I'd suspect you have redefined a global variable as a local variable somewhere. Check the address of the flag variable when you are debugging and make sure it is the same in __set_flag() and outwith the interrupt, where you think it has not been updated.
I also think that the polling loop in your ISR is poor code and you should find a better way to wait for the transmitter to be ready for the next character.
Thanks to all the feedback i got from the members. Well the idea of declaring all the "variables volatile" did the trick . strcmp() uses const var* so i couldn't use it . I had to write my own custom string compare function. All this minor things solved my problems.
Related
I'm writing code for stm32l011 MCU and it have to do one basic task for now - wait for a specific byte(predefined by me) from the UART and following "\r\n" or "\n\r" sequence. If it receives that, it set's a null pointer to the address of the predefined char, which is read and handled in the main loop.
volatile uint8_t uart_buff[UART_BUFF_LEN] = {'\0'};
volatile uint8_t *uart_data = NULL;
volatile uint8_t *uart_stack = uart_buff+2;
void USART2_IRQHandler(void){
if(LL_USART_IsActiveFlag_RXNE(USART2)){
*uart_stack = LL_USART_ReceiveData8(USART2);
user_uart_send_byte(*uart_stack);
//same as if(!(strcmp((uart_stack-1), "\r\n") || strcmp((uart_stack-1), "\n\r")))
if((*uart_stack == '\r' || *uart_stack == '\n') && (*(uart_stack-1) == '\r' || *(uart_stack-1) == '\n'))
{
uart_data = uart_stack - 2;
uart_stack = uart_buff+2;
}
uart_stack++;
}
}
and main:
extern volatile uint32_t systick_counter_ms;
extern volatile uint8_t *uart_data;
int main(void){
init();
while(1)
{
LL_GPIO_TogglePin(GPIOB, LL_GPIO_PIN_3);
//delay_ms(1); //without that it doesn't want to work
if(uart_data)
{
adc_transmit_reading(*uart_data);
uart_data = NULL;
}
}
}
I wrote the C program above and it didn't seem to work. But when I introduced delay in the main loop it just magically sprang to life. Why is that? Key things to note:
There's echo from the UART so I'm sure that it handles the interrupt properly in both cases, also I tried to remove optimizations of the compiler(which optimizes for size(Os)) by using volatile variables. Also the delay is made by while loop, which waits interrupt which increments variable every millisecond.
My layman's guess is that because I'm only looping around that uart_data pointer, somehow the synchronization between the interrupt and main loop isn't happening.
Thanks in advance :)
The problem is that you have indicated that your uart_data points to volatile data. But in your loop, you are testing the pointer and not the data.
So you must indicate that your pointer is volatile as well:
extern volatile uint8_t * volatile uart_data;
You can find more information in this post: Why is a point-to-volatile pointer, like "volatile int * p", useful?
I am using stm32 timer interrupt.
File 1: (interrupt function)
static int flag = 50;
void timer_inter_handler(){
//...
flag = some changes integer;// not 0, it is changed
#if 0 // **** note
printf("%d\r\n", flag);
#endif
}
int get_flag(){
return flag;
}
File 2: (other file)
int task1(){
static int fccount = 0;
while(1){
fccount++;
if ( fccount%50000 == 0 )
{
printf("%d\r\n", get_flag());
// ...
}
}//while(1)
}
Note:
If this on, task1 could print correct flag data changes. But if it is off, task1 could only print default 50value during system initialization for a couple of time. Then all the flag data printed is 0.
I do not know why this happen. No other place update the var flag. Any clue?
What you need is:
volatile static int flag = 50;
The volatile keyword tells the compiler that the flag variable can change in an interrupt. If the keyword is not there, then the flag variable will not be able to change. That is why you don't see it changing. The #if 0 printf(...) might be forcing the compiler to access the variable.
I found the problem.The problem is inside timer interrupt, hal_adc_start(read and stop), by reading adc value, the timer interrupt routine is hold.
Once I move hal_adc_read, it works fine.
I have a strange situation under C/Visual Studio on a Windows 7 platform. There is a problem from time to time and I spent a lot of time to find it. The problem is within a third party library, for which I have the complete code. There a thread is created (the printLog statements are from myself):
...
plafParams->eventThreadFlag = 2;
printLog("before CreateThread");
if (plafParams->hReadThread_p = CreateThread(NULL, 0, ( LPTHREAD_START_ROUTINE ) plafPortReadThread, ( void * ) dlmsInstance, 0,
&plafParams->portReadThreadID) )
{
printLog("after CreateThread: OK");
plafParams->eventThreadFlag = 3;
}
else
{
unsigned int lasterr = GetLastError();
printLog("error CreateThread, last error:%x", lasterr);
/* Could not create the read thread. */
...
...
return FAILURE;
}
printLog("SUCCESS");
...
...
The thread function is:
void *plafPortReadThread(DLMS_GLOBALS *dlmsInstance)
{
PLAF_PARAMS *plafParams;
plafParams = (PLAF_PARAMS *)(dlmsInstance->plafParams);
printLog("start - plafPortReadThread, plafParams->eventThreadFlag=%x", plafParams->eventThreadFlag);
while ((plafParams->eventThreadFlag != 1) && (plafParams->eventThreadFlag != 3))
{
if (plafParams->eventThreadFlag == 0)
{
printLog("exit 1 - plafPortReadThread, plafParams->eventThreadFlag=%x", plafParams->eventThreadFlag);
CloseHandle(plafParams->hReadThread_p);
plafFree((void **)&plafParams);
ExitThread(0);
break;
}
}
printLog("start - plafPortReadThread, proceed=%d", proceed);
...
Now, when the flag is set before the while loop is started within the thread, everything works OK:
SUCCESS
start - plafPortReadThread, plafParams->eventThreadFlag=3
But sometimes the thread is quick enough so the while loop is started before the flag is actually set within the outer part.
The output is then:
start - plafPortReadThread, plafParams->eventThreadFlag=2
SUCCESS
Most surprisingly the while loop doesn't exit, even after the flag has been set to 3.
It seems, that the compiler "optimizes" the flag and assumes, that it cannot be changed from outside.
What could be the problem? I'm really surprised. Or is there something else I have overseen completely? I know, that the code is not very elegant and that such things should better be done with semaphores or signals. But it is not my code and I want to change as little as possible.
After removing the whole while condition it works as expected.
Should I change the struct or its fields to volatile ? Everybody says, that volatile is useless in our days and not needed anymore, except in the case, where a memory location is changed by peripherals...
Prior to C11 this is totally platform-dependent, because the effect you are observing is due to the memory model used by your platform. This is different from a compiler optimization as synchronization points between threads require the compiler to insert barrier instructions, instead of, e.g., making something a constant. For C11 for section 7.17.3 specifies the different models. So your value is not optimized out statically, thread A just never reads the value thread B wrote, but still has its local value.
In practice many projects don't use C11 yet, and thus you will likely have to check the documentation of your platform. Note that in many cases you don't have to modify the type of the variable for the flag (in case you can't). Most memory models specify synchronization points that also forbid reordering of certain instructions, i.e. in:
int x = 3;
_Atomic int a = 1;
x = 5;
a = 2;
the compiler will often have to ensure that x has the value 3 when a has the value 1, and that when a is assigned the value 2, x will have the value 5. volatile does not participate in this relationship (in the C/C++ 11 models - often confused because it does participate in Java's happened-before), and is mostly useless, unless your writes should never be optimized out because they have side-effects such as a LED blinking which the compiler can't understand:
volatile int x = 1; // some special location - blink then clear
x = 1; // blink then clear
x = 1; // blink then clear
In the code below, I can see that the timer is working normally as the LED is always blinking. But the value of the count variable never changes inside the second while.
I don't know what could possibly go wrong?
// count variable used only in main and TIM2_IRQHandler.
uint8_t count=0;
int main(void)
{
count=0;
SystemInit();
GPIOInit();
NVIC_Configuration();
TIM_Configuration();
init_USART3(115200);
// All initialization is ok.
USART_puts(USART3, "\r\nConnection ok.\r\n");// Working normally
while (1)
{
if(asterixok==1)// No problem. This code if ok ->>process continue next step.
{
GPIO_SetBits(GPIOD , GPIO_Pin_12); // Led on (ok)
count=0;// count going to zero, timer working, must be change in there
while(1)
{
//Led blinking continue
//Timer query working normal led (13) blink.
//There is a problem
if(count>5) // Timer working, count never change in timer interrupt query (WHY)
{
GPIO_SetBits(GPIOD , GPIO_Pin_14); // LED OFFFFFFFFFFFFFFFF
USART_puts(USART3, "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\r\n");
goto nextstate;
}
}
nextstate:
GPIO_SetBits(GPIOD , GPIO_Pin_15); // Led never going on because code step in while loop.
}
}
}
void USART3_IRQHandler(void)
{
if( USART_GetITStatus(USART3, USART_IT_RXNE) )
{
unsigned char t = USART3->DR;
if(t=='*')
{
asterixok=1;
}
}
}
void TIM2_IRQHandler(void)
{
if ( TIM_GetITStatus(TIM2 , TIM_IT_Update) != RESET )
{
TIM_ClearITPendingBit(TIM2 , TIM_FLAG_Update);
count++;
if(count>100)
count=0;
if( display )
{
GPIO_ResetBits(GPIOD , GPIO_Pin_13);
}
else
{
GPIO_SetBits(GPIOD , GPIO_Pin_13);
}
display = ~display;
}
}
I have tried with another Discovery board but the problem continues.
Please help. I'm going crazy!
You should declare count as volatile, as such :
volatile uint8_t count;
While compiling main the compiler was able to prove that count was not modified in the loop body, and so it probably cached its value in a register and maybe even optimized out the if statement. You could verify that by looking at a disassembly. The compiler does not know about interrupts as per the standard and so is permitted to perform such optimizations. Qualifying count as volatile will forbid the compiler from making these optimizations, forcing it to reload the variable from memory each time it is used.
In this simple case volatile will be enough but please be aware that it doesn't guarantee atomicity of operations, and it doesn't prevent the compiler and CPU from reordering instructions around accesses to the variable. It only forces the compiler to generate memory access instructions each time the variable is used. For atomicity you need locks, and to prevent reordering you need memory barriers.
I am trying to write to use the multiple serial interface on the 68HC12 but am can't get it to talk. I think I've isolated the problem to not being able to write to the SC1DRL register (SCI Data Register Low).
The following is from my SCI ISR:
else if (HWRegPtr->SCI.sc1sr1.bit.tdre) {
/* Transmit the next byte in TX_Buffer. */
if (TX_Buffer.in != TX_Buffer.out || TX_Buffer.full) {
HWRegPtr->SCI.sc1drl.byte = TX_Buffer.buffer[TX_Buffer.out];
TX_Buffer.out++;
if (TX_Buffer.out >= SCI_Buffer_Size) {
TX_Buffer.out = 0;
}
TX_Buffer.full = 0;
}
/* Disable the transmit interrupt if the buffer is empty. */
if (TX_Buffer.in == TX_Buffer.out && !TX_Buffer.full) {
Disable_SCI_TX();
}
}
TX_Buffer.buffer has the right thing at index TX_Buffer.out when its contents are being written to HWRegPtr->SCI.sc1drl.byte, but my debugger doesn't show a change, and no data is being transmitted over the serial interface.
Anybody know what I'm missing?
edit:
HWRegPtr is defined as:
extern HARDWARE_REGISTER *HWRegPtr;
HARDWARE_REGISTER is a giant struct with all the registers in it, and is volatile.
It's likely that SC1DRL is a write-only register (check the official register docs to be sure -- google isn't turning up the right PDF for me). That means you can't read it back (even with an in-target debugger) to verify your code.
How is HWRegPtr defined? Does it have volatile in the right places to ensure the compiler treats every write through that pointer as something which must happen immediately?