Main Loop hangs
Main Loop hangs
Guys,
I am facing a particular problem. I notice at times, the main loop stops functioning even though interrupts works fine. Any idea why this would happen. I've set traps for stacks, address, osi fail, etc, uart errors, nothing shows up. It has been particularly notice under following conditions:
a) While writing to UART 2 and an INT0 happens which actually makes a write to I2C.
Also, we notice at times the MCU resets on it own ..and nothing shows up in the traps or error bits.
Would appreciate inputs..
Thanks in advance.
I am facing a particular problem. I notice at times, the main loop stops functioning even though interrupts works fine. Any idea why this would happen. I've set traps for stacks, address, osi fail, etc, uart errors, nothing shows up. It has been particularly notice under following conditions:
a) While writing to UART 2 and an INT0 happens which actually makes a write to I2C.
Also, we notice at times the MCU resets on it own ..and nothing shows up in the traps or error bits.
Would appreciate inputs..
Thanks in advance.
jpc, thanks. The codes has run into many lines, I dont know which part to past.
But with your experience, would you think the following could be reason:
a) The place where the MCU Main loop stops, I've a delay_ms(10000) and I also have delay_ms(100) a couple of times in the interrupt, hence when the interrupt is called there could be a clash of the same delay_ms function ?
But with your experience, would you think the following could be reason:
a) The place where the MCU Main loop stops, I've a delay_ms(10000) and I also have delay_ms(100) a couple of times in the interrupt, hence when the interrupt is called there could be a clash of the same delay_ms function ?
i would NEVER put any delay in interrupt, actually i try to avoid delays as proposed by the compiler completely, the main loop should run as fast as possible to get most out of your MCU. By using timers ( i usually have a 1 ms timer ISR running, this can provide many software timers/delay counters) instead of delays your MCU can do something usefull instead of wasting many cycles by a delay_ms( 10000) , imagine how much significant code could be executed by these.
Without knowing your interrupt-source, you also might have the next interrupt pending by the time the delay(s) allow returning from the ISR.
Without knowing your interrupt-source, you also might have the next interrupt pending by the time the delay(s) allow returning from the ISR.
Au royaume des aveugles, les borgnes sont rois.
Jpc, Thanks. As you notice I've only 4 months experience with this product against your 4 years..wow..your word is law.
from what I understood from your reply is..with a delay_ms(10000), the MCU actually stops for 10 seconds.. not allowing any other code to run and one should use timer delays when they want a delay in the interrupt routine and other routines.. and as far as possible avoid any delay in interrupts..
would you be able to share the code for timer delays..it would be highly appreciated..
from what I understood from your reply is..with a delay_ms(10000), the MCU actually stops for 10 seconds.. not allowing any other code to run and one should use timer delays when they want a delay in the interrupt routine and other routines.. and as far as possible avoid any delay in interrupts..
would you be able to share the code for timer delays..it would be highly appreciated..
what PIC are you using? The different family's have different interrupt vectors, for P30 as most simple example i start with something like this
now you have a global msecs , inside the interrupt you may already make seconds,minutes/whatever you need .
In order to read these in your main, do make sure the interrupt will not interfere with the access if it is not atomic.
Code: Select all
// using TMR3
//initialize first by this code
const msecvalue : word = clock_khz div 4;
var msecs : longint;
...
msecs := 0;
PR3 :=msecvalue;
T3CON := %1000000000000000;
IEC0.7 := 1; // enable timer3 interrupts
...
procedure ms_tick_clock; org $22;
begin
inc(msecs);
IFS0.7 := 0; // clear flag
end;
In order to read these in your main, do make sure the interrupt will not interfere with the access if it is not atomic.
Au royaume des aveugles, les borgnes sont rois.
first for your pic i think the vector is at $24 instead of the $22 on the P30.
In my example i use longint variable, if you read this fromthe main loop this will take more than one cycle so there is a risk that the ISR will occur between these introducing an error. The simplest solution is to disable interrupt while reading this variable, e.g.
In my example i use longint variable, if you read this fromthe main loop this will take more than one cycle so there is a risk that the ISR will occur between these introducing an error. The simplest solution is to disable interrupt while reading this variable, e.g.
Code: Select all
function get_time : dword;
begin
IEC0.7 := 0; // disable timer3 interrupts
get_time := msecs; // copy the value
IEC0.7 := 1; // reenable timer3 interrupts
end;
Au royaume des aveugles, les borgnes sont rois.