56303 | 563xx | 5680 | 56805 | 5680x | 56F80 | 56F800DEMO | 56F805 | 56f807 | 56F830 | ADC | Bootloader | Codec | CodeWarrior | CW5 | CW6 | Debugger | DSP56303 | DSP56303EVM | DSP563xx | DSP5680 | DSP56800 | DSP56807 | DSP56858 | DSP56858EVM | DSP56F803 | DSP56F805 | DSP56F807 | DSP56F80x | DSP56F826 | DSP56F827 | DSP56F8xx | EVM | FFT | Flash_over_jtag | GPIO | Interrupt | Interrupts | JTAG | LCD | Linker | MCF5307 | Metrowerks | Modulus | MSCAN | PCMaster | PWM | Quad | Rif | RTOS | SDK | SPI

I'm using a 56F8323 in my application. I have one of the pins of the GPIOB port (pin 4) configured to drive a simple transistor switch (intended as a hardware reset for a particular circuit). I have the pin configured as an output and the DSP is supposed to assert the pin high if it receives a particular CAN message. That functionality works perfectly if I receive the message. However, I've noticed in the lab that occasionally the pin is asserted randomly. I've tried debugging this by setting a breakpoint at the function that drives the output pin, but when the random assertion occurs, the software doesn't break. I've also tried detecting it by polling the pin's output and I am able to hit a breakpoint thnat way. This looks like a noise issue. I don't think it's EMI related but it might be. On a whim, I tried observing another unused pin both on the same port and on thne A port (B0 and A4 respectively). I found that when the spurious assertion occurs, the B0 pin also asserts but the A4 does not. Is this an issue with the port? What is the most likely culprit in my hnardware to cause this? Any ideas? Myron Mychal Wausau, WI

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )

> --- In , "Myron Mychal" <mmychal@y...> wrote: > I'm using a 56F8323 in my application. I have one of the pins of > the GPIOB port (pin 4) configured to drive a simple transistor > switch (intended as a hardware reset for a particular circuit). > I have the pin configured as an output and the DSP is supposed > to assert the pin high if it receives a particular CAN message. > > That functionality works perfectly if I receive the message. > However, I've noticed in the lab that occasionally the pin is > asserted randomly. I've tried debugging this by setting a > breakpoint at the function that drives the output pin, but when > the random assertion occurs, the software doesn't break. I've > also tried detecting it by polling the pin's output and I am able > to hit a breakpoint that way. > > This looks like a noise issue. I don't think it's EMI related but > it might be. On a whim, I tried observing another unused pin both > on the same port and on thne A port (B0 and A4 respectively). > I found that when the spurious assertion occurs, the B0 pin also > asserts but the A4 does not. > > Is this an issue with the port? What is the most likely culprit > in my hnardware to cause this? Any ideas? > Myron Mychal > Wausau, WI I don't think the data register is changing in your function. All of the peripherals in the 56F8300 series have memory mapped control registers. So a rogue pointer in your code can walk through the memory associated with GPIOB and change its behavior. All that need happen is that the data register change because of the rogue pointer. What pins in GPIOB are assigned as output? Are they changing as well when B4 changes? If so, I would guess that your code is walking over the data register for GPIOB.

(You need to be a member of motoroladsp -- send a blank email to motoroladsp-subscribe@yahoogroups.com )