1
\$\begingroup\$

Based on datasheet page 17:

GPIO registers are located on the ARM Cortex M0+ IO bus for fastest possible single-cycle I/O timing, allowing GPIO toggling with rates of up to 15 MHz.

And I used a tiny code (based on the LPCOPEN library) to test its speed:

Chip_GPIO_SetPinDIROutput(LPC_GPIO_PORT, 0, 12);

while(1)
{
    Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, 12, true);
    Chip_GPIO_SetPinState(LPC_GPIO_PORT, 0, 12, false);

}

When I trace this GPIO pin by logic analyzer, it's toggling around 250 kHz which is far from the mentioned value in datasheet.

I also used PLL to increase main clock and system clock for achieving better speed:

Chip_IRC_SetFreq(96000000, 24000000);

but even for different values 250 kHz is the highest frequency which I can achieve. Decreasing PLL speed cause decrements on output frequency of GPIO and also I know I can achieve better speed with assembly code but 250 kHz is so far away from datasheet, and it seems the MCU are not able to exceed this limit (there are same substance for 60 MHz/30MHz – 60MHz/15MHz and so) Also 250 kHz is maximum speed which pins in the SPI peripheral state can toggled.

EDIT: I'm aware that for full speed test, needed to code in assembly directly with registers, but as I said before the problem is after increasing the 12 MHz main clock, GPIO cannot toggle faster, and also toggling speed for SPI CLOCK pin is limited to this speed too.

\$\endgroup\$
7
  • \$\begingroup\$ The datasheet mentions registers, but your code does not access the registers directly. \$\endgroup\$
    – CL.
    Commented Aug 15, 2016 at 8:05
  • \$\begingroup\$ Note to other members: FYI this question has also been duplicated on parallel threads at NXP's LPC Community and the edaboard forum. \$\endgroup\$
    – SamGibson
    Commented Aug 15, 2016 at 8:11
  • 2
    \$\begingroup\$ You're using function calls to do it and probably don't have the optimiser on. Try the equivalent assembly code . \$\endgroup\$
    – pjc50
    Commented Aug 15, 2016 at 10:49
  • 1
    \$\begingroup\$ @MHD - "Is there any rules that prevent us from asking questions in other internet communities which asked before in stackexchange?" In "How To Ask Questions The Smart Way" it recommends "Don't shotgun-blast all the available help channels at once, that's like yelling and irritates people. Step through them softly." You are already getting replies on both other forums, so readers here may want to see those replies, before deciding whether to reply. I was going to reply here, but don't want to waste time duplicating the ongoing effort there. \$\endgroup\$
    – SamGibson
    Commented Aug 15, 2016 at 10:53
  • 1
    \$\begingroup\$ In addition to the inefficiency of the software approach being used, and the possibility that the PLL isn't actually running or being used, it is also theoretically possible that the logic analyzer is undersampling - the pin could be toggling faster than the analyzer can capture, in which case what you would be seeing is an artifact related to the difference between the analyzer sampling frequency and the toggling frequency. If you can change the analyzer sampling frequency (preferably by a small amount) see if the toggle frequency changes. \$\endgroup\$ Commented Aug 15, 2016 at 15:51

1 Answer 1

-1
\$\begingroup\$

You have no way of KNOWING for a fact that your clock is what you think it is. I recommend using a timer, with an interrupt triggered on reaching a count or overflow that simply toggles a bit to verify your system clock.

You should set the interrupt to be triggered at some reasonable rate -- maybe 1kHz.

Incorrect clock setup may or may not be your issue, but it is really a mandatory first step in debugging such problems. Many ARM processors have pretty complicated startups that involve changing clock modes when the clock is trying to do something but can't.

\$\endgroup\$
1
  • \$\begingroup\$ As I know there is a functions which enable us to route various sections clock to the pins and measure it's value by logic analyzer \$\endgroup\$
    – MHD
    Commented Jul 2, 2018 at 11:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.