After some study, trial and error, I created a simple project for a NXP LPC1768, to test its timer interrupt. This project contains only startup_LPC17xx.s, system_LPC17xx.c, C-main.c, and timer.c.
C-main.c:
#include "lpc17xx.h" #include "timer.h" extern uint32_t SystemFrequency; int main(void) { SystemInit(); Timer_Init_n_Enable( LPC_TIM0, (SystemFrequency/8-1) ); NVIC_EnableIRQ(TIMER0_IRQn); /* LED Init */ LPC_GPIO2->FIODIR |= 0x000000FF; /* P2.0 to P2.7 LEDs defined as output */ while(1); }
timer.c:
#include "lpc17xx.h" #include "timer.h" void TIMER0_IRQHandler(void) { LPC_TIM0->IR = (1u<<0); // Reset the MR0 Interrupt; Writing a zero has no effect. LPC_GPIO2->FIOPIN ^= (1<<7); // Toggle LED. } void Timer_Init_n_Enable( LPC_TIM_TypeDef * TimerX, uint32_t TimerInterval ) { TimerX->MR0 = TimerInterval; TimerX->MCR |= (1u<<0) | (1u<<1); // Interrupt and Reset on MR0 TimerX->TCR |= (1u<<0); // Enable Timer Counter and Prescale Counter }
This project seemed to work.
But if I change the timer.c to:
void TIMER0_IRQHandler(void) { LPC_GPIO2->FIOPIN ^= (1<<7); // Toggle LED. LPC_TIM0->IR = (1u<<0); // Reset the MR0 Interrupt; Writing a zero has no effect. }
It doesn't work.
If I change the timer.c to:
void TIMER0_IRQHandler(void) { LPC_GPIO2->FIOPIN ^= (1<<7); // Toggle LED. LPC_TIM0->IR = (1u<<0); // Reset the MR0 Interrupt; Writing a zero has no effect. NVIC_ClearPendingIRQ(TIMER0_IRQn); }
It seemed to works.
I guess that, it doesn't work because I clear the LPC_TIM0->IR interrupt flag too late, so the NVIC generates a pending interrupt for LPC_TIM0->IR.
I don't have a LPC23xx now, so I can't verify my guess. I guess that, it will still work:
void Timer0Handler(void) __irq { FIO2PIN ^= (1<<7); // Toggle LED. T0IR = 1; /* Clear Interrupt Flag */ VICVectAddr = 0; /* Acknowledge Interrupt */ }
I think it is usual that, programmer needs to do something to identify which kind of interrupt was triggered, before clear the interrupt flag.
So, if my understanding is correct, how do I know that, I did NOT clear the interrupt flag too late within an ISR?
It is quite frustrated that, I can't even handle a simple timer interrupt properly. Maybe my understanding has never been correct.
I also found a link: my.st.com/.../Flat.aspx
Where, it shows:
void TIM3_IRQHandler(void) { TIM3_SR->field.UIF = 0; //clear interrupt flag setBit(IRQ_CLRPEND0, BIT29); //clear NVIC pending interrupt }
But, always clear NVIC pending interrupt within an ISR, sounds strange to me for a MCU equipped with NVIC.
Correction for the above link
my.st.com/.../Flat.aspx
Re-Correction for the above link
Removed the last ¤tviews=569
Hi John,
Quite likely the issue here is that the ISR ends before the bus cycle for accessing the interrupt flag has completed. Just spending a bit more time in the ISR and clearing the flag as early as possible should help. You might also try if a synchronization barrier (DSB) after clearing the flag helps. Pulse interrupts also help but might not always be available.
Regards Marcus http://www.doulos.com/arm/
I'm not sure about any need for a line: VICVectAddr = 0; /* Acknowledge Interrupt */
It is needed for LPC23xx but not used in the NXP code bundle for the 17xx. But the LPC23xx has very weak integration with the NVIC requiring it to lookup the jump vector while the LPC17xx/Cortex-M3 have strong NVIC integration with dedicated interrupt vectors.
The 17xx code bundle have timer interrupt handlers looking like (reindented since their code look lousy):
void TIMER0_IRQHandler (void) { if ( LPC_TIM0->IR & (0x1<<0) ) { LPC_TIM0->IR = 0x1<<0; /* clear interrupt flag */ timer0_m0_counter++; } if ( LPC_TIM0->IR & (0x1<<1) ) { LPC_TIM0->IR = 0x1<<1; /* clear interrupt flag */ timer0_m1_counter++; } if ( LPC_TIM0->IR & (0x1<<4) ) { LPC_TIM0->IR = 0x1<<4; /* clear interrupt flag */ timer0_capture0++; } if ( LPC_TIM0->IR & (0x1<<5) ) { LPC_TIM0->IR = 0x1<<5; /* clear interrupt flag */ timer0_capture1++; } return; }
Interesting that they have a "return" in the function - lousy developer may think all functions need a return.
But anyway - you always need to take care of the individual interrupt sources within a device. For an UART, you may manage some interrupt sources by just reading th receive data register or writing to the transmit holding register. But for the timer, you need to acknowledge exactly what sources within a timer you handled.
Since the timer can have multiple compare/match active, you can get new bits set in the timer while you already are in your ISR - so by clearing the events you did handle, the NVIC will know if it needs to issue yet another interrupt or if you managed to pick up all pending events from the device.
That would be a possibilty that NXP would need to answer - it has nothing specifically to do with Keil.
It might also be specific to NXP's implementation - so that ST's examples would not be applicable...
"It might also be specific to NXP's implementation - so that ST's examples would not be applicable..."
I don't think so. I don't think NXP have any options open to them in this case, given the integration of the NVIC in the core.
But the help function in the ST example may represent extra clock cycles explaining the problem with the NXP chip and inlined acknowledge of the timer flag directly before the return.
"I don't think so. I don't think NXP have any options open to them in this case, given the integration of the NVIC in the core."
You may well be right; but NXP would be the ones to confirm it - rather than Keil.
Or, perhaps, the core documentation from ARM.
Or The Definitive Guide to the ARM Cortex-M3 by Joseph Yiu - see: http://www.keil.com/books/armbooks.asp
Or it might be an interaction between the NVIC and the Timer (which is NXP-specific)...?
When I said "It doesn't work", I mean "LED doesn't toggle."
LPC1768 has been released to the market for quite a long time, and I did check the errata, it did not mention anything about Timer or "bus cycle for accessing the interrupt flag".
Base on your replies, I guess that, my understanding is not that incorrect, and though I can "clear the interrupt flag first", but "just toggle a LED" before "clear the interrupt flag" should be fine. Am I right?
The LPC1768 MCU I am evaluating, is a '-' Initial device revision MCU. I think that, the symptom I observed, is quite easy to reproduce. I don't know how to contact NXP, and will not try to contact NXP at the moment. I need to pass the trial period first.
RTC doesn't work, Strange Timer behavior, sounds like I am a quite lousy programmer.
Many thanks for your kind help.
Is your RTC powered? It is in a separate power domain.
When you only use one interrupt source from a device and that source have limited interrupt repeat time, then it doesn't matter where you acknowledge the interrupt source.
If the interrupt source can have short spans between interrupts, then you should acknowledge the interrupt source as soon as possible so the bit is ready to latch next interrupt from that source.
I think my RTC is powered. It has the main power, and also a battery. I found out that, even it has the main power, it still needs a battery.
[3] The RTC typically fails when Vi(VBAT) drops below 1.6 V.
The Errata did not provide enough information about RTC problem, my google search tell me that, "The Real Time Clock (RTC) does not work reliably within the temperature specification." (from Errata) means, most RTC on the '-' revision LPC1768 will NOT work.
Your first point of contact should be your Distributor.
Don't NXP have forums any more?
"I did check the errata"
It may not be an erratum - it might be "expected behaviour".
"RTC doesn't work, Strange Timer behavior, sounds like I am a quite lousy programmer."
Don't be so hard on yourself.
Like many things, it's common to have a number of problems and questions when you start working with a new processor. It's all part of the learning curve - at least that's my experience.
The NXP forum might be worth a try, but the one I look at has plenty of questions and precious few answers.
Try here:
http://forums.nxp.com/
Indeed it is!
And it is the role of a good technical Distributor to support you through the learning curve.
All the manufacturers (including NXP) are pushing their Cortex offerings hard at the moment, so there are lots of training opportunities - many free!
For example, see: http://www.keil.com/events/
I think the RTC problems are only related to the temperature span - but alas, NXP don't want to give any information about what the safe temperature span is. I have been looking at replacing 23xx with 17xx but avoided it because of the RTC issue.