Hi,
I've a problem with a missing interrupts.
My device is based on g25 and 3.10 kernel.
During usart transmissions there where many missing bytes. After doing some tests, it came that all data is leaving transmitter,
but not all data is receving by my device. The situation is on a first attached picture. Upper line shows RXRDY interrupts, bottom line shows incoming data. At some point interruts are missing for a some time (up to 20ms), after i'm receiving OVRE, and then RXRDY appears again. It's not periodically. It can happen few times per second or once per few seconds.
http://postimg.org/image/xgizh405n/
I thought this situation is specific only for serial port driver, but no.
There are an interrupts from timer (should be every 4ms), and gap is visible again.
http://postimg.org/image/5jh6k0k09/
When using i2c the same thing is happening.
My question is: how can i debug it?
Missing interrupts
Moderator: nferre
- blue_z
- Location: USA
Post
Why are you using PIO rather than DMA?
That doesn't look like an interrupt every 4msec. Why the ~50% duty cycle?
Regards
Re: Missing interrupts
Then you mean the issue is during USART reception.rumcajs666 wrote:During usart transmissions there where many missing bytes. After doing some tests, it came that all data is leaving transmitter, but not all data is receving by my device.
Why are you using PIO rather than DMA?
What is that depicting?rumcajs666 wrote:There are an interrupts from timer (should be every 4ms), and gap is visible again.
http://postimg.org/image/5jh6k0k09/
That doesn't look like an interrupt every 4msec. Why the ~50% duty cycle?
Regards
Post
Re: Missing interrupts
Thanky You for an answer.
Driver is slightly modified and adjusting it to DMA requires work i'd like to avoid.
That's the 50% duty.
http://postimg.org/image/oe041b4z3/
This is the same signal as before, but chart is magnified.
You can see line inside red circle in the middle, also signal width value in upper right corner.
One more thing. Event if usart is not in use, interrupts are also disappearing.
I know i can use DMA.
But problem with interrupt will stay, and can be an obstacle in future.
Regards.
Not only during USART reception, but i found this issue there.Then you mean the issue is during USART reception.
USART was configured this way.Why are you using PIO rather than DMA?
Driver is slightly modified and adjusting it to DMA requires work i'd like to avoid.
I'm running hardware timer, and gpio is being toggled in its interrupt handler, every 4ms.What is that depicting?
That doesn't look like an interrupt every 4msec. Why the ~50% duty cycle?
That's the 50% duty.
http://postimg.org/image/oe041b4z3/
This is the same signal as before, but chart is magnified.
You can see line inside red circle in the middle, also signal width value in upper right corner.
One more thing. Event if usart is not in use, interrupts are also disappearing.
I know i can use DMA.
But problem with interrupt will stay, and can be an obstacle in future.
Regards.
- blue_z
- Location: USA
Post
The event that happens every millisecond turns the GPIO on and off, but the less-frequent event just toggles the GPIO?
What changes have you made to the kernel, esp. to ISRs?
Use the occurrence counters in /proc/interrupts to find the active interrupts.
Then use GPIO pins to profile the active states of those ISRs.
If you cannot identify the high-priority interrupt that's causing the blocking, then you may have to instrument at91_irq_suspend() and at91_irq_resume().
Regards
Re: Missing interrupts
So you're inconsistent?rumcajs666 wrote:I'm running hardware timer, and gpio is being toggled in its interrupt handler, every 4ms.
That's the 50% duty.
The event that happens every millisecond turns the GPIO on and off, but the less-frequent event just toggles the GPIO?
So what applications, services, daemons are executing on the system?rumcajs666 wrote:One more thing. Event if usart is not in use, interrupts are also disappearing.
What changes have you made to the kernel, esp. to ISRs?
Use the occurrence counters in /proc/interrupts to find the active interrupts.
Then use GPIO pins to profile the active states of those ISRs.
If you cannot identify the high-priority interrupt that's causing the blocking, then you may have to instrument at91_irq_suspend() and at91_irq_resume().
Regards
Who is online
Users browsing this forum: Google [Bot] and 3 guests