FridgeFreezer

MCF52259 GPIO pins deasserting themselves, help tracking down

Discussion created by FridgeFreezer on Mar 22, 2011
Latest reply on Apr 29, 2013 by TomE

Yes it's me again! :smileytongue:

 

Micro is MCF52259 LQFP144, code is C in CW7.2.

 

We have a weird problem - we are running a timer (DTIMx) and toggling GPIO pins to control a motor (step & direction & power level) but every so often after setting the GPIO pins (PORTTI) they flip back to their previous state about ~2uS after the ISR exits (our clock is 48MHz). The weird thing is it doesn't appear to be an electrical noise problem, the micro can actually see the register is wrong by reading it back (we can set a breakpoint and it will break when the bit flips)

 

I have checked everything I can think of - we're not nesting interrupts (eg interrupting another read-modify-write of the PORTTI register), we're not re-triggering the interrupt erroneously, we're not modifying the register anywhere else in the code (as far as I can see), the pin assignment is not being changed, etc.

 

We can catch the situation with this code (variables are just there to make debugging easier):

 

void __interrupt__ motor_isr(void){  MCF_GPIO_PORTTI |= MCF_GPIO_PORTTI_PORTTI0; // Set bit}// Now catch it in another rutineif(!(MCF_GPIO_PORTTI & MCF_GPIO_PORTTI_PORTTI0)){    halt(); // Breakpoint}

 

This is happening with more than one pin on PORTTI, it seems to make no difference if we use it as MCF_GPIO_PORTTI or use SETTI/CLRTI to change the output, or always read values from it as SETTI. It also makes no difference if we read-modify-write the register as a byte (eg (MCF_GPIO_SETTI |= MCF_GPIO_PORTTI_PORTTI6)) or if we define a union and modify individual bits (which I think should compile out to bit set/bit clear commands instead).

 

As ever, I'm sure it will turn out to be something stupid I've done incorrectly... but any advice on how to track it down / what to look for would be greatly appreciated!

Outcomes