cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F100 dev board interrupt not working

saudkhanis
Associate II
Posted on June 17, 2014 at 12:41

 

 

The original post was too long to process during our migration. Please click on the attachment to read the original post.
7 REPLIES 7
Posted on June 17, 2014 at 13:19

You never call EXTI_Configuration, the EXTIx_IRQHandler's don't clear the interrupt source.

You're USART output routine should front test TXE rather than back test it.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
saudkhanis
Associate II
Posted on June 17, 2014 at 15:12

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6fZ&d=%2Fa%2F0X0000000bsp%2FgHGmu82C_3RTrFy04uyn8tCug7AE9cgIyE1h75QFSUA&asPdf=false
Posted on June 17, 2014 at 16:04

Ok, so you've addressed one issue I raised. You still don't clear the interrupt source in the handler.

How are you debugging this? How do you know the interrupt is not entering?

What is the nature of the input signal? Should it be floating? Pull down to ground, switch to supply?
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
saudkhanis
Associate II
Posted on June 17, 2014 at 16:38

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6fe&d=%2Fa%2F0X0000000bsr%2FKQArWIe0EbUZx8wZ.fgKkFgRTUyyMrQEocZjPpHoV_c&asPdf=false
saudkhanis
Associate II
Posted on June 18, 2014 at 00:05

The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6fj&d=%2Fa%2F0X0000000bst%2FOi.FF1NMkP2ySV8Zhg50rYolbWaBEIHpbC6OChzoGH0&asPdf=false
Posted on June 18, 2014 at 00:15

Yes, the clearing code looks Ok.

Can you diagram the circuit? Is this using a switch, or some other logic, could the signal bounce?

How brief is the excursion of the signal? Could you reflect the pin states directly to an LED, and confirm the states transition as you expect.
Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
saudkhanis
Associate II
Posted on June 18, 2014 at 12:54

I have attached the circuit design to this reply. The signal cant have debounce because that is already been handled by another circuit. The T15 signal goes high for 2 - 3 seconds (then goes low) and T50 goes low and stays low . Initially when T50 goes high T15 becomes high (first interrupt - PA1 interrupt) too but as T15 goes low after 2 - 3 seconds, T50 doesnt. T50 is then requested to go low (second interrupt - PA0 interrupt). It should be noted from the circuit design I have attached that the T15 and T50 signals are inverted so if T50 is high, at the STM32 board end it will seem as low.

I hope this makes sense. Clive you think you can help? The PA1 interrupt occurs a few times but not every time whereas, PA0 interrupt does not occur at the falling edge. It sometimes randomly gets interrupts but at the rising edge. Any idea what can be causing this?

________________

Attachments :

Circuit_Design.pdf : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I0tD&d=%2Fa%2F0X0000000bf6%2FlhLX_f3HfAA1v7tkahgRdNpY34mFbWqbLKabvJJ6eHY&asPdf=false