first code:
//------------------------------------------------------------------------------
/// Interrupt handlers for TC interrupts. Toggles the state of LEDs
//------------------------------------------------------------------------------
char token = 0;
void TC0_IrqHandler(void) {
volatile unsigned int dummy;
dummy = AT91C_BASE_TC0->TC_SR;
if(token == 1) {
PIO_Clear(&leds[0]);
PIO_Set(&leds[1]);
token = 0;
}
else {
PIO_Set(&leds[0]);
PIO_Clear(&leds[1]);
token = 1;
}
}
//------------------------------------------------------------------------------
/// Configure Timer Counter 0 to generate an interrupt every 250ms.
//------------------------------------------------------------------------------
void ConfigureTc(void) {
unsigned int div;
unsigned int tcclks;
AT91C_BASE_PMC->PMC_PCER = 1 << AT91C_ID_TC0; // Enable peripheral clock
TC_FindMckDivisor(1, BOARD_MCK, &div, &tcclks); // Configure TC for a 4Hz frequency and trigger on RC compare
TC_Configure(AT91C_BASE_TC0, tcclks | AT91C_TC_CPCTRG);
AT91C_BASE_TC0->TC_RC = (BOARD_MCK / div) / 1; // timerFreq / desiredFreq
IRQ_ConfigureIT(AT91C_ID_TC0, 0, TC0_IrqHandler); // Configure and enable interrupt on RC compare
AT91C_BASE_TC0->TC_IER = AT91C_TC_CPCS;
IRQ_EnableIT(AT91C_ID_TC0);
printf(" -- timer has started \n\r");
TC_Start(AT91C_BASE_TC0);
}
it's just interrupt timer and it's event (handler) but when I run some
while(1) {
// action
after ConfigureTc() it both cycle and interrupt timer are freezes... Why could that be? Should I add another timer and avoid while(1) ?
while(1) {
printf("hello");
}
-- this breaks (freeze) loops (yes, if I don't use timer it works as it must)
I'll venture an actual answer here. IME, 99% of the time my boards 'go out' with no response on any input and no 'heartbeat' LED-flash from the low-priority 'blinky' thread, the CPU has flown off to a prefetch or data abort handler. These handlers are entered by interrupt and most library-defined default handlers do not re-enable interrupts, so stuffing the entire system. Often, they're just endless loops and, with interrupts disabled, that's the end of the story:(
I have changed my default handlers to output suitable 'CRITICAL ERROR' messages to the UART, (by polling it - the OS/interrupts are stuft!).
Related
I've been trying to configure & run hardware timer over SAML21 MCU to generate a 100ms delay i.e. ISR is supposed to hit at every 100ms. But it is observed that after starting the timer ISR is hitting at every 10us and changing the Prescaler & Compare register values isn't creating any difference in the 10us interval. Please review my code and let me know where I'm doing wrong.
I'm trying to configure Timer1(TC1) in 16bit mode, using GCLK_GENERATOR_1 as its clock source running at 8MHz frequency(CPU Main Clock:16MHz). The timer is expected to cause overflow interrupt every 100ms.
TcCount16 *tc_hw1 = NULL; /* Pointer to TC1 hardware registers Initilized later */
void init_timer1(void)
{
struct tc_module tc_inst1;
struct tc_config conf_tc1;
tc_get_config_defaults(&conf_tc1);
conf_tc1.clock_source = GCLK_GENERATOR_1;
conf_tc1.clock_prescaler = TC_CLOCK_PRESCALER_DIV64; /* 8MHz/64 = 125KHz*/
conf_tc1.reload_action = TC_RELOAD_ACTION_GCLK;
conf_tc1.counter_size = TC_COUNTER_SIZE_16BIT;
conf_tc1.count_direction = TC_COUNT_DIRECTION_UP;
conf_tc1.counter_16_bit.value = 0x0000;
/** Rest of the settings are used as defaults **/
while (tc_init(&tc_inst1, TC1, &conf_tc1) != STATUS_OK){
}
tc_set_top_value(&tc_inst1, 12500); /* Set counter compare top value */
/* Enable interrupt & Set Priority */
tc_hw1 = &(tc_inst1.hw->COUNT16); /* Initialize pointer to TC1 hardware register */
tc_hw1->INTENSET.reg |= TC_INTFLAG_OVF; /* Enable Overflow Interrupt */
NVIC_SetPriority(TC1_IRQn, 2);
NVIC_EnableIRQ(TC1_IRQn);
tc_enable(&tc_inst1); /*Start The TIMER*/
}
void TC1_Handler(void)
{
if((tc_hw1->INTFLAG.reg) & (TC_INTFLAG_OVF))
{
port_pin_toggle_output_level(PIN_PB03);
}
system_interrupt_clear_pending(SYSTEM_INTERRUPT_MODULE_TC1);
}
Debugger Information: I can see that the timer register is configured correctly but the COUNT register is not incrementing itself every time I pause to capture the debug info it shows only 0x0000 values.
Please help. Thanks!
I resolved the issue actually it's kind of mandatory to clear the timer OVF bit in the INTFLAG register. So the interrupt handler should've been like this:
void TC1_Handler(void)
{
if((tc_hw1->INTFLAG.reg) & (TC_INTFLAG_OVF))
{
tc_hw1->INTFLAG.reg = TC_INTFLAG_OVF; /*Clears the flag by writing 1 to it*/
port_pin_toggle_output_level(PIN_PB03);
}
system_interrupt_clear_pending(SYSTEM_INTERRUPT_MODULE_TC1); /*Not necessarily needed*/
}
There seems to be a conflict between timer 2 and timer 3. This is a MIPS board and instead of using assembly language to program; I am using C. Timer1 is for a count which works properly. Timer2 is for a blinking LED which works properly. Timer3 is for switching count directions. But there is a conflict between timer2 and timer3. Does anyone know where the conflict is? I have to comment out DelayInit3(); in order for the code to execute properly.
void __ISR(_TIMER_2_VECTOR, ipl2) Timer2Handler(void)
{
// clear the interrupt flag
mT2ClearIntFlag();
PORTToggleBits(IOPORT_B, BIT_10);
}
void __ISR(_TIMER_23_VECTOR, ipl2) Timer23Handler(void)
{
// clear the interrupt flag
mT3ClearIntFlag();
if (direction != 0){
direction < 1;
}
else{
direction != 0;
}
}
int main()
{
DeviceInit();
DelayInit1();
DelayInit2();
// DelayInit3();
}
void DelayInit1()
{
unsigned int tcfg1;
/* Configure Timer 1. This sets it up to count a 10Mhz with a period of 0xFFFF
*/
tcfg1 = T1_ON|T1_IDLE_CON|T1_SOURCE_INT|T1_PS_1_8|T1_GATE_OFF|T1_SYNC_EXT_OFF;
OpenTimer1(tcfg1, 0xFFFF);
}
void DelayInit2()
{
unsigned int tcfg2;
// Config Timer 2. This sets it to count 312500 Hz with a period of T2_TICK
tcfg2 = T2_ON | T2_SOURCE_INT | T2_PS_1_32;
OpenTimer2(tcfg2, T2_TICK);
// Now enable system-wide multi-vector interrupt handling
INTEnableSystemMultiVectoredInt();
// Configure timer 2 interrupt with a priority of 2
ConfigIntTimer2(T2_INT_ON | T2_INT_PRIOR_2);
// Clear interrupt flag
mT2ClearIntFlag();
}
void DelayInit3()
{
unsigned int tcfg3;
// Config Timer 3. This sets it to count 312500 Hz with a period of T3_TICK
tcfg3 = T3_ON | T3_SOURCE_INT | T3_PS_1_256;
OpenTimer23(tcfg3, T23_TICK);
// Now enable system-wide multi-vector interrupt handling
INTEnableSystemMultiVectoredInt();
// Configure timer 3 interrupt with a priority of 2
ConfigIntTimer23(T23_INT_ON | T23_INT_PRIOR_2);
// Clear interrupt flag
mT3ClearIntFlag();
}
You should also toggle the bits at every timer end. The order that you are toggling is wrong. At every timer finish, you are toggling BIT10 twice, i.e. getting it back to initial position.
You can use code like this.
count = 0; // in Init.
while(1)
{
if (IFS0bits.T2IF == 1)
{
//if timer == period, toggle the LED
count++;
PORTToggleBits(IOPORT_B, BIT_10);
if (count %2 == 0)
{
DelayMs(2);
PORTToggleBits(IOPORT_B, BIT_11);
}
if (count > 3)
count = 0;
mT2ClearIntFlag();
}
}
You are toggleing the Bit 10 with a delay of 2 ms to it's first state. Even if this works, you will not notice.
I am working on a board which comprises LPC1768 microcontroller. All I want to do is to create an accurate time delay using osdelay function of CMSIS RTOS API. I have set my systick time tick count to 10000.But when I use osdelay(1000) in my thread, it doesn't creates delay period of 1 second as it should do !
Here is the source code
#include"cmsis_os.h"
#include"lpc17xx.h"
void Thread1 (void const *argument) {
while (1) {
LPC_GPIO2->FIOPIN = 0x00000001;
osDelay(1000);
LPC_GPIO2->FIOPIN = 0x00000000;
osDelay(1000);
}
}
osThreadId main_ID,led_ID1,led_ID2;
osThreadDef(Thread1,osPriorityNormal, 1, 0);
int main (void)
{
SystemInit();
LPC_PINCON->PINSEL4 = 0x00000000;
LPC_GPIO2->FIODIR = 0xffffffff;
osKernelInitialize ();
led_ID1 = osThreadCreate(osThread(Thread1), NULL);
osKernelStart ();
}
Now, my problem is with osdelay(1000) not providing a delay of 1000ms as it should do with systick timer tick value set to 1000.
I have the following sketch, and the numTicks variable is not incrementing, the sketch compiles fine to the Arduino, but for whatever reason the variable "numTicks" is not incrementing.
/*
* kegboard-clone-4-KegCop
* This code is public domain
*
* This sketch sends a receives a multibyte String from the iPhone
* and performs functions on it.
*
* This Arduino sketch is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU Public License
* along with this sketch. If not, see <http://www.gnu.org/licenses/>.
*
* Examples:
* http://arduino.cc/en/Tutorial/SerialEvent
* http://arduino.cc/en/Serial/read
* http://stackoverflow.com/questions/16532586/arduino-sketch-that-responds-to-certain-commands-how-is-it-done/
* http://davebmiller.wordpress.com/2011/01/18/arduino-flowmeter/
* http://forum.arduino.cc/index.php?topic=52003.0
* http://arduino.cc/en/Reference/AttachInterrupt
* https://github.com/just-kile/Zapfmaster2000/blob/master/src/zapfmaster2000-zapfkit-avr/draftkitAVR.ino
*
* TODO:
* - eventually get code working with the SF800 flow sensor / flowmeter
*
*/
// flow_A LED
int led = 4;
// relay_A
const int RELAY_A = A0;
// string / serial event variables
String inputString = ""; // a string to hold incoming data
boolean stringComplete = false; // whether the string is complete
boolean valve_open = false;
// FLOWMETER SHIT
// flowmeter 0 pulse (input) = digital pin 2
// https://github.com/Kegbot/kegboard/blob/master/arduino/kegboard/kegboard_config.h
// which pin to use for reading the sensor? kegboard-mini shield has digital pin 2 allocated
// the SF800 outputs 5400 pulses per litre
// The hall-effect flow sensor (SF800) outputs approximately 5400 pulses per second per litre/minute of flow
// SF800 default (5400 ticks/Liter == 5.4 ticks/mL == 1/5.4 mL/tick)
int flowmeterInterrupt = 0; // changed from byte
int flowmeterPin = 2; // changed from byte
int flowmeterPinState = 0; // variable for storing state of sensor pin
// read RPM
int rpmcount = 0;
int rpm = 0;
unsigned long lastmillis = 0;
// NEW GLOBALS - 29JUL13
// initial ticks on flow meter
volatile unsigned int numTicks = 0;
// interval for flow meter frequency
int interval = 250;
volatile long previousMillis = 0;
void setup() {
// initialize serial
// Serial.flush(); // flush the serial buffer on setup.
Serial.begin(115200); // open serial port, sets data rate to 9600bps
Serial.println("Power on test");
inputString.reserve(200);
valve_open = false;
// relay for solenoid cut off valve
pinMode(RELAY_A, OUTPUT);
// flowmeter shit
pinMode(flowmeterPin, INPUT);
digitalWrite(flowmeterPin, HIGH); // Need to set these HIGH so they won't just tick away
// The Hall-effect sensor is connected to pin 2 which uses interrupt 0.
// Configured to trigger on a RISING state change (transition from HIGH
// state to LOW state)
attachInterrupt(flowmeterInterrupt, count, RISING);
}
void open_valve() {
digitalWrite(RELAY_A, HIGH); // turn RELAY_A on
valve_open = true;
}
void close_valve() {
digitalWrite(RELAY_A, LOW); // turn RELAY_A off
valve_open = false;
}
void flow_A_blink() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
delay(1000); // wait for one second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
delay(1000); // wait for a second
}
void flow_A_blink_stop() {
digitalWrite(led, LOW);
}
void flow_A_on() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
}
void flow_A_off() {
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
}
// flowmeter shit
void getFlow4() {
// Serial.println("im here");
// Serial.println(sensorPin);
flowmeterPinState = digitalRead(flowmeterPin);
// Serial.println(sensorPinState);
volatile unsigned long currentMillis = millis();
// if the predefined interval has passed
if(currentMillis - previousMillis > interval) { // Uptade every 1/4 second, this will be equal to reading frecuency (Hz).
// disconnect flow meter from interrupt
detachInterrupt(flowmeterInterrupt); // Disable interrupt when calculating
// check, whether any flow was detected
if (numTicks >= 0) {
// start message to computer with tick message symbol
Serial.print("Ticks:");
// send amount of ticks for last interval
Serial.print(numTicks);
}
// clean buffer
Serial.flush();
// reset amount of ticks
numTicks = 0;
// set new start value for interval counter
previousMillis = currentMillis;
// reattach interrupt
attachInterrupt(flowmeterInterrupt, count, RISING);
}
if(flowmeterPinState == LOW) {
flow_A_off();
// Serial.println("don't blink");
}
if(flowmeterPinState == HIGH) {
flow_A_on();
// Serial.println("blink damnit");
}
if(stringComplete) {
if(inputString.equals("{close_valve}\n")) {
// Serial.println("close vavle.");
close_valve();
}
return;
}
}
// flow meter interrupt function
void count(){
numTicks++;
}
/*
* Main program loop, runs over and over repeatedly
*/
void loop() {
if(stringComplete) {
// Serial.println(inputString);
if(inputString.equals("{open_valve}\n")) {
// Serial.println("inputString equates :)");
open_valve();
}
if(inputString.equals("{close_valve}\n")) {
// Serial.println("close vavle.");
close_valve();
}
if(valve_open) {
// Serial.println("valve_open = true");
inputString = "";
stringComplete = false;
while(numTicks <= 1000) {
getFlow4();
}
}
// clear the string:
inputString = "";
stringComplete = false;
}
//Serial.println("over and over");
}
/*
SerialEvent occurs whenever a new data comes in the
hardware serial RX. This routine is run between each
time loop() runs, so using delay inside loop can delay
response. Multiple bytes of data may be available.
*/
void serialEvent() {
while(Serial.available()) {
// get the new byte:
char inChar = (char)Serial.read();
// add it to the inputString:
inputString += inChar;
// if the incoming character is a newline, set a flag
// so the main loop can do something about it:
if (inChar == '\n') {
stringComplete = true;
}
// Serial.println(inputString.length());
}
}
The reason the numTicks variable is not changed is probably due to the interrupt not triggering. You should put a breakpoint in count() to confirm this. Then you need to figure out why the interrupt isn't triggering as it should, but that is another question.
Sorry for my prior answer. I did not completely understand the problem.
First of all, are you using an Arduino UNO, if so then check the board pin labelled digital pin 2 which is mapped as "int.0" and ensure that the interrupt line from the flowmeter is connected to this pin. (see: http://arduino.cc/en/Reference/AttachInterrupt).
Per Chris' comments above, the count() routine is interrupt driven code, and it appears to be coded correctly: numTicks is defined as volatile; and count() does NOT issue I/O commands such as printf; and it does NOT return any values.
The code sample that you provide does not isolate or highlight the problem. I would write a test sketch that is just a bare bones implementation of "opening" the sensor and then sensing an interrupt from the flow meter and reporting that back to the console from the main loop. If you can get code that detects one interrupt from the flow meter to work, then add more code to report on the number of interrupts in one second, then 1/2 second, etc.
Finally, in your provided code you have the fragment:
if(valve_open) {
// Serial.println("valve_open = true");
inputString = "";
stringComplete = false;
while(numTicks <= 1000) {
getFlow4();
}
}
Since numTicks is incremented by the interrupt routine count, as a matter of principal I would NOT test it unless some of kind of serialization was implemented. getFlow4() detaches the interrupt which is one way to serialize access to numTicks. Note. in theory code can update numTicks without serialization but any value returned is not necessarily accurate as the interrupt might have fired and increased numTicks.
It seems like your application is interested in knowing the number of ticks per second?? in which case you do NOT need to test numTicks prior to stopping the interrupts. All you might need is code that once every second checks numTicks and if you can live with dropping a count then zero out numTicks without even detaching the interrupt. However, sampling numTicks is more like polling which is what an interrupt is trying to avoid.
So, since the code is keeping track of intervals then divide the interval by numTicks to get a Hz value and don't zero out numTicks or reset the interval until they get close to rolling over.
The code ended up working, it was hardware issue with the connections from the flowmeter (>.>)
You are never actually calling your count() method. You should either insert numTicks++; into the code where you wish to increase the count (recommended way), or call your count() method where you wish to increase the count. Here the count() method is only defined and not called, but it would make more sense to just increment the counter in the code since that is the only thing your defined method is doing.
Recently, I write a linux module to generate interrupt every 20us using watch dog. I use the global timer to test whether the interval between two interrupts is 20us. But I find the result is greater than 20us. So I change the value of watchdog counter in the interrupt function to regulate the error if the error is bigger enough. After I add the code of regulating error, the result is better than before in most interrupts, while there still exist some huge error between two interrpts, and the error is much lager than 20us.
Thank you for reading my question, I hope it can be solved as soon as possible.
This is interrupt handler code:
static irqreturn_t wd_interrupt(int irq, void *dev_id) {
long long regulate_value;
long load_value;
long long err;
tick_start = read_global_timer();
//the cmp_cycle is the value of global timer if the interrupt are not delayed
cmp_cycle += (long long)wd_load;
err = tick_start - cmp_cycle;
//if the err is biger than cmp_err, I will write a new value to watch dog to eliminate the error
if(err > cmp_err)
{
regulate_value = (long long)wd_load - err;
load_value = least_load;
// if the err is very big, the regulate_value may be too small
if(regulate_value > (long long)load_value)
load_value = (long)regulate_value;
__raw_writel(load_value, twd_base + TWD_WDOG_COUNTER);
}
if(err > max_err)
max_err = err;
return IRQ_HANDLED;
}
this is my code to start the watch dog and global timer
static int kthread_init(void *arg) {
unsigned long ctl;
int err;
if((err = request_irq(30, wd_interrupt, 0, NULL, NULL)) < 0)
{
printk("request_irq err:%d\n",err);
return 0;
}
gt_base = ioremap((OMAP44XX_LOCAL_TWD_BASE - 0X400), SZ_256);
cmp_cycle = 0;
// wd_load = twd_timer_rate / 50000; //20us
wd_load = twd_timer_rate / 500; //2000us
cmp_err = 1000;
least_load = wd_load - 2000;
tick_start = 0;
max_err = 0;
//init the global timer
__raw_writel(0x00, gt_base + GLOBAL_TIMER_CONTROL);
__raw_writel(0x00, gt_base + GLOBAL_TIMER_COUNTER_LOW);
__raw_writel(0x00, gt_base + GLOBAL_TIMER_COUNTER_UPPER);
//switch the watch dog to timer mode
__raw_writel(0x12345678, twd_base + TWD_WDOG_DISABLE);
__raw_writel(0x87654321, twd_base + TWD_WDOG_DISABLE);
//write the watch dog load register
__raw_writel(wd_load, twd_base + TWD_WDOG_LOAD);
//write the watch dog control register
ctl = TWD_TIMER_CONTROL_ENABLE | TWD_TIMER_CONTROL_IT_ENABLE | TWD_TIMER_CONTROL_PERIODIC;
//start the watch dog and global timer
__raw_writel(ctl, twd_base + TWD_WDOG_CONTROL);
__raw_writel(0x01, gt_base + GLOBAL_TIMER_CONTROL);
set_current_state(TASK_INTERRUPTIBLE);
schedule();
while(!kthread_should_stop())
{
set_current_state(TASK_INTERRUPTIBLE);
schedule();
}
__raw_writel(0x0, twd_base + TWD_WDOG_CONTROL);
printk("wd_load:%lu,max_err:%lld\n",wd_load,max_err);
return 0;
}
My guess is that your handler together with all the Linux wrapping code can't finish running in 20us, so the following interrupts get delayed. Try increasing the delay and see if that helps.
I think what you are seeing is other interrupts happening. When for example the network card sends an interrupt the kernel enters interrupt mode and process the network interrupt. When it returns from that the cpu sees that your interrupt is pending and triggers that. But you've lost the time the network interrupt took.
You would have to change any other interrupt handler that takes longer than say 10us to reenable interrupts and run the actual handler in SYS/SVC mode.