TIMER INTERRUPT ISSUE

[contact2]

Posted on September 28, 2013 at 12:45

Hello,

I am trying to make a timer interrupt routine, which executes every 0.25us. The problem I am facing that the code length in the routine changes the duration for example running an instruction at 72MHz, the next time the routine execute is 0.35us. It seems the the timer starts counting after returning from the IRQ routine, instead of running just after overflow. I am using Auto-Reload register with value 18. Tell me what I am missing.Regards. #timer2 #keil #stm32f303

[contact2]

Posted on September 28, 2013 at 13:08

BTW, I am using KEIL ARM, and ST-LINK Debugger for time observation.

[Tesla DeLorean]

Posted on September 28, 2013 at 13:26

What do you need to do at 250ns?

The Cortex-M3 has a 12 cycle latency for interrupts as it is, and your budget appears to be 18, I don't see this happening. The system will just saturate. If you need to toggle an output, or generate a pulse, I would suggest using the timer hardware to do that, rather than use an interrupt.

[contact2]

Posted on September 28, 2013 at 13:42

I want to implement DSP algorithm for my project ''Software Defined Radio: Implementation of FM Demodulation Algorithm''. According to my design I am using a sampling frequency of 4MHz. Which is processable after some frequency down conversion hardware. I am using STM32F303 which is a Cortex-M4 Processor. I was using previously dsPIC, it was giving me a sampling duration of exact 4MHz. But in this controller, I am facing this issue, which I think is the programming issue. I think there is some bit in the timer register, which starts the timer again after IRQ routine ends.

[Tesla DeLorean]

Posted on September 28, 2013 at 13:48

If you want to capture a signal at 4 MHz, you'll want a TIM to pace a DMA operation at that rate.

If you have an update interrupt it is going to keep going, but at some point you can't service it quick enough. If you have to have software doing this processing, then you should perhaps sit in a tight and cycle controlled loop, and not use interrupts. You should perhaps also place your code in CCM RAM which would be much faster and more predictable than FLASH.

[contact2]

Posted on September 28, 2013 at 13:53

please explain it technically in detail.

[contact2]

Posted on September 28, 2013 at 14:04

Thank you Clive,

:p Actually I am new with these ARM based controllers, started few days before. I am attaching a zipped file in which the problem is occurring. I think you can find an easy way to overcome this issue please see it. ________________ Attachments : Blinky1.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0Sz&d=%2Fa%2F0X0000000bbi%2FfSKiB5MDBKDU2uePxUzPBt6aN38TBpihF8QTL_M6C0c&asPdf=false

[Tesla DeLorean]

Posted on September 28, 2013 at 15:26

The project itself is a bit of a mess, try this

________________ Attachments : CleanProject.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0c3&d=%2Fa%2F0X0000000bbg%2FsvzzGIgAuNfU9R5r5N6RPagFI0MlfzlGovI66Ek_IIQ&asPdf=false

[contact2]

Posted on September 28, 2013 at 15:45

Thanks for managing this project. The interval no matter how long it is, still gets effected with the length of code inside that routine. It increases the duration.

[Tesla DeLorean]

Posted on September 28, 2013 at 17:44

Indeed, and as I indicated there is no practical way for you to be interrupting at a 4 MHz rate, you need to re-evaluate how you are going to solve this problem.

If you are setting up the ADC for a 4 MSps rate you will need to use DMA to capture and store those measurements in memory, you'll then want to look at processing them 10 or 100 at a time, or some other decimation factor you prefer. Polling the DMA HT/TC flags might be more efficient than using an interrupt if the timing still remains tight. Perhaps you can diagram the flow and rates you're hoping to process here.