Weird GPIO edge spike with MCF51JM128VLH ?

Showing results for 
Search instead for 
Did you mean: 

Weird GPIO edge spike with MCF51JM128VLH ?

Contributor I

Hello community,

I'm using standard GPIO of my MCF51JM128VLH for data communication with a LCD screen.

I get huge but not oscillating edge-spike while I'm tryng to get a decent rate of flow. 250us edge to edge.

It come to the point that non of the signal is left and the output is just oscillating spike to spike from what I understand.

Nothing is connected to my GPIOs at the moment. I got a 100nF and 10uF capacitors near my supply input.

It's Output pull-up configured.

Slew rate control doesn't seems to have any effect with or without.

Drive strenght is low.

Input filter is disabled.

I tried different timer CPU settings, timer settings or without the use of a timer. Same result.

You can find attached the test project and screenshot of my init. This is really simple code. I'm delaying changes on portE data using a timer. That's about all.

The standard GPIO is this slow ? I can't find anything in the Reference Manual.

Thanks in advance for any advice,


Labels (1)
Tags (1)
0 Kudos
3 Replies

Contributor I

I'm waiting for a new clean PCB. I'll let you know if its still happening. Thanks a lot for your answers

0 Kudos

Specialist I

Please include a capture of the oscilloscope trace showing the "spikes". You should also get a screen shot of the same waveform when you're running at a lower frequency. Try to send a proper screen grab rather than taking a photo of the oscilloscope with your phone as the latter are often hard to read. You should also detail the voltage levels you're getting. Are the "spikes" going above the 3.3V level and below 0V or are they small spikes to 3.3V, which would imply the cable you're using is shorted at the far end. Or maybe terminated with a low resistance and you have a low current driver that can't supply enough current.

How LONG is the trace and the cable between the GPIO pin and the LCD? I'm guessing you're getting reflections from the far end of the cable.

> 250us edge to edge

So that means your cable is of the order of 125us long at 70% of the speed of light, or about 26 kilometres long.

And you're sending data at 4 kHz. That's not very fast.

Did you mean nanoseconds instead of microseconds?

That still implies you have about 26 metres of cable there.

For anything over a few centimeters you should be using a properly designed transmission line. You can either terminate the line at the far end in its characteristic impedance, or (easier) put a series resistor in the line of the characteristic impedance. If you don't know what that is, try 30, 50 75 or 100 ohms and see what the waveform looks like. The transmitter also has to be able to provide enough current. Most modern chips aren't rated for this. But on the positive side, the programmable power or slew rate of the pins can often allow them to generate good waveforms on various external loads without external components. But you have to experiment with this to get it right.

> The standard GPIO is this slow

The "spikes" have nothing to do with what's inside the CPU. As Vincente said, show us the schematic. Including the length of cable to the LCD panel plus the documented interface of that unit.

GPIO is a lot slower than you'd expect anyway. That's why that chip you're using has an RGPIO (Rapid GPIO) interface. They call it that as it is a lot faster than the normal one. Access to the GPIO port registers can cause as much as 12 wait states or more on some of these CPUs. That's because the peripherals are running on a slower clock than the CPU core, so the CPU is forced to wait. On some chips the peripherals are on the far side of one or even two "CPU to peripheral bridges" that add their own delays. I've used a chip that inserted 200 wait states on a GPIO read or write! It was actually recommended to program the DMA controller to write to the pins for you (so the CPU could do something else instead of waiting).

Other posts on this forum have been from people trying to benchmark the CPU or functions by turning a GPIO pin on and off around the function they're trying to measure. They end up measuring the GPIO delay without realising it.

Read some of my replies here for some of the details:

Flexbus delay 

Help with MCF5475 speed problem. 

In one of the comments, the poster is "using a 24MHz MCF51JM28 to write a 320x240 TFT LCD", but is using RGPIO.

coldfire V1 MCF51JM128 speed problems 


0 Kudos

NXP TechSupport
NXP TechSupport


is there only one pin? or all the port?

would be possible that you share the schematics?


0 Kudos