Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
68332 - TPU CISR register ignored?
16 views
Skip to first unread message
Niels Kristian Jensen
Oct 5, 2011, 5:51:21 AM10/5/11
to
Hi all, I've got this target running:
M68332 processor with the built-in TPU.
The Motorola/Freescale documentation says that when the TPU requests an
interrupt, it also sets a bit in the CISR register. When the ISR finishes
servicing the interrupt, it should reset the bit in the CISR by reading
then writing a zero bit to the bit in question.
I found a bug in the target, the wrong bit was cleared. But the interrupt
handling worked anyway.
So I've built a new version of the firmware which ignores the CISR register
completely, i.e. the bits are never cleared.
It works - interrupt handling is not affected. I've checked the code
execution with a Lauterbach ICE trace debugger. When I break the code, some
bits are set in the CISR (but not all the expected bits).
I'm very confused by this finding. Any explanation on this would be very
nice.
Best regards,
Niels Kristian
M68332 processor with the built-in TPU.
The Motorola/Freescale documentation says that when the TPU requests an
interrupt, it also sets a bit in the CISR register. When the ISR finishes
servicing the interrupt, it should reset the bit in the CISR by reading
then writing a zero bit to the bit in question.
I found a bug in the target, the wrong bit was cleared. But the interrupt
handling worked anyway.
So I've built a new version of the firmware which ignores the CISR register
completely, i.e. the bits are never cleared.
It works - interrupt handling is not affected. I've checked the code
execution with a Lauterbach ICE trace debugger. When I break the code, some
bits are set in the CISR (but not all the expected bits).
I'm very confused by this finding. Any explanation on this would be very
nice.
Best regards,
Niels Kristian
Niels Kristian Jensen
Oct 5, 2011, 7:53:38 AM10/5/11
to
Niels Kristian Jensen <n...@internetDYTgruppen.dk> wrote in
news:4e8c2899$0$290$1472...@news.sunsite.dk:
> M68332 processor with the built-in TPU.
>
> The Motorola/Freescale documentation says that when the TPU requests
> an interrupt, it also sets a bit in the CISR register. When the ISR
> finishes servicing the interrupt, it should reset the bit in the CISR
> by reading then writing a zero bit to the bit in question.
>
> I found a bug in the target, the wrong bit was cleared. But the
> interrupt handling worked anyway.
>
> So I've built a new version of the firmware which ignores the CISR
> register completely, i.e. the bits are never cleared.
Well, not completely. The ICE seems unable to break at internal addresses
in the 68332. And I found another clear in some assembly code.
In short: I have to analyze this some more.
news:4e8c2899$0$290$1472...@news.sunsite.dk:
> M68332 processor with the built-in TPU.
>
> The Motorola/Freescale documentation says that when the TPU requests
> an interrupt, it also sets a bit in the CISR register. When the ISR
> finishes servicing the interrupt, it should reset the bit in the CISR
> by reading then writing a zero bit to the bit in question.
>
> I found a bug in the target, the wrong bit was cleared. But the
> interrupt handling worked anyway.
>
> So I've built a new version of the firmware which ignores the CISR
> register completely, i.e. the bits are never cleared.
in the 68332. And I found another clear in some assembly code.
In short: I have to analyze this some more.
tom_u...@optusnet.com.au
Oct 6, 2011, 6:54:44 PM10/6/11
to
You're right. The manual says "To clear a status flag, read CISR,
then write a zero to the appropriate bit.".
The "write a zero to clear" is usually a sign of a bad design and always dangerous because you might accidentally clear another bit that came on between the read and the write. That's why Motorola's "write one to clear" is so much better. There must be some sort of hardware interlock that remembers which bits were set on the "read" so that only the ones read as set during the read get cleared when written with a zero.
You should probably never read this register unless you immediately intend to write back to it with only the one bit you are intending to clear changed to a zero. If you are reading this at other times then it may be getting cleared "by accident".
I'd suggest you join the Freescale Forums and ask questions there.
Tom
then write a zero to the appropriate bit.".
The "write a zero to clear" is usually a sign of a bad design and always dangerous because you might accidentally clear another bit that came on between the read and the write. That's why Motorola's "write one to clear" is so much better. There must be some sort of hardware interlock that remembers which bits were set on the "read" so that only the ones read as set during the read get cleared when written with a zero.
You should probably never read this register unless you immediately intend to write back to it with only the one bit you are intending to clear changed to a zero. If you are reading this at other times then it may be getting cleared "by accident".
I'd suggest you join the Freescale Forums and ask questions there.
Tom
0 new messages