MCF5329 LCDC: Reading ISR register loses events

[TomE]

I've been working on code that performs "animation" on an MCF5329 LCD Controller.

We're using standard double-buffering. Display one video buffer while writing to the next, then swapping them. This has to be done during the "vertical retrace" period.

This is a lot harder than it should be, as the LCDC doesn't have a signal or interrupt that uniquely tells you that the LCDC has obeyed the command to swap to the other buffer.

So I've been reverse engineering the timing, and when I hear back from Freescale on this I'll publish details.

Meanwhile I wrote some code to reverse-engineer the timing by reading the LCDC_ISR and Interrupt Controller registers.

It didn't go well. The LCD_ISR register contains status bits, two of interest being "BOF" and "EOF" (Beginning and End of Field). With the frame and memory timing I expect to see the following:

0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 16760us, 4us

 That means the time from BOF to EOF was 16760us, and then the time to the next BOF was 4us. What I'm actually getting is this:

0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 117344us, 4us     Multiple EOF Missed0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 16760us, 16768us  BOF Missed0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 83816us, 16768us  EOF and then BOF missed0 -> 2 -> 1, 16760us, 16768us0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 67052us, 16768us0 -> 2 -> 1, 16760us, 16768us0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 16760us, 4us0 -> 2 -> 1, 83816us, 16768us

The LCD_ISR register is documented as:

22.3.17 LCDC Interrupt Status Register (LCD_ISR)
The read-only interrupt status register indicates whether an interrupthas occurred. The status bit is set when the interrupt condition is met.If any bit in this register is set and the corresponding bit in theLCD_IER register is set, an LCD interrupt is asserted to the interruptcontroller.The status bit is cleared by reading the register.

In order to measure the timing, my code is in a loop continuously reading the register.

Which is sometimes CLEARING the bits before they can be read as being set!

It seems to be that a read of this register happening at the same time as the hardware trying to set bits in this register results in the "clear the bits on read" operation winning.

If I put delays in the loops so they read less often, then the missed-reads of the bits happens less often, but it still happens.

This register is provided to be read by an interrupt service routine to determine which interrupt source happened, and to clear that source. When used "synchronously" like this it should work OK, with the risk of missing interrupts if there are multiple ones being used (like both Frame and Graphics Window interrupts).

It doesn't look to support "asynchronous reading" though.

This is an unusual interrupt status register. Most of the ones in other peripherals are "write one to clear" rather than "read to clear". What is happening here shows why "write one to clear" is such a good design.

Watch out for any other registers in other peripherals that are "read to clear". They might be causing problems for other design with "missed events".

Tom

[TomE]

I reported this problem to Freescale and got the following response:

25/05/11 09:31
Thank you for forwarding the very detailed information,the problem is much clearer now. I've made the designteam aware of this new information as well, and willlet you know when I have a proper response to your questions.

 And then later, and my responses to their answers:

10/06/11 10:041) For the SSAR reload question, the SSAR is reloaded atthe exact time that the EOF interrupt occurs. This is whythe recommendation in the reference manual is to load itat BOF, to ensure it won't be misloaded. Hopefully thisinformation can enable you to achieve the LCD refresh thatyou are trying to create. 2) For the question about missing status bit changes, thepriority of clearing the interrupt is higher than the priorityof writing it. So your assumption was correct. I'll make anote to the docs team to add some clarification to avoidhaving other people run into this issue like you did. Theyare also looking at a design change for future use of thatmodule. The design of the module was such that the ISRregister should only be read after an interrupt occurs, andnot continuously.

The above explanation (of when the reload happens) doesn't match the manual, so anyone reading the manual might be mislead as I was:

    Table 22-13. LCD_POR Field Descriptions
    The POS field is read by the LCDC once at the
    beginning of each frame.

It is also ambiguous as there are two BOFs. Obviously it has to be before the data load into the FIFO, but this could be expressed better.

The clarification seems to be wrong. My testing also indicates the SSAR can be reloaded up to 1.5us PRIOR to the EOF interrupt bit being set in the status register. The "window" seems to be between 1.5us and 0us prior to and the status register update itself. It may be at the "exact time" somewhere in the pipeline, but the status register changes later.

I have to accomodate this "mystery delay" in my code.

The manual does mention the reloading of the SSAR, but this is documented in the PANNING section, and most people don't do panning and wouldn't read that section.

As for the interrupts being lost, this controller can generate PAGE and WINDOW interrupts. It would be very easy to have these happening close enough together that losing one of them when clearing the previous one is a real risk.

Tom

[TomE]

I have just received more informaiton on the "SSAR Reload Question". I started a thread on this question (19 months ago), so I'll put the answers in that one:

https://community.freescale.com/thread/61205

Tom