LPCXpresso IDEのトピックRe: Probllem with LPC1769 & CMSIS

Probllem with LPC1769 & CMSIS

lpcware — Thu, 16 Jun 2016 02:32:18 GMT

Content originally posted in LPCWare by jab on Wed Jun 13 09:24:06 MST 2012
Hi,

I have a custom board with a LPC1769 on it. I have been having some issues with the board so I set-up a simple program:

int main(void)
{
    LPC_PINCON->PINSEL3 &= ~(3<<22);
    LPC_PINCON->PINSEL3 |=  (1<<22);
    LPC_SC->CLKOUTCFG = (1<<8);

    while(1)
    {

    }
    return 0 ;
}

This code just sets up the clock out pin to display the Main System Clock.

However when I run the program I see nothing on the pin. Looking at the system through debug I see the system starts and then just hangs. LPCxpresso says the program is running but there is nothing going on. It never reaches the initial breakpoint (set by LPCxpresso to be the first line in main).

I noticed that sometimes I get a SIGSTOP fault when debugging. Tracing this back it seems that the SystemInit() function tries to change the clock and the system fails.

If I comment out the systeminit() function from the cr_startup_lpc176x.c file the system works. The clock output is routed to the clockout pin and I can verify it with an oscilloscope.

My question is why the automatically generated code is failing. I had no such problem with the Cortex M0 boards I have built in the past. Is this a known problem?

Re: Probllem with LPC1769 & CMSIS

lpcware — Thu, 16 Jun 2016 02:32:19 GMT

Content originally posted in LPCWare by Ex-Zero on Wed Jun 13 09:37:07 MST 2012

Quote: jab

int main(void)
{
    LPC_PINCON->PINSEL3 &= ~(3<<22);
    LPC_PINCON->PINSEL3 |=  (1<<22);
    LPC_SC->CLKOUTCFG = (1<<8);

    while(1)
    {

    }
    return 0 ;
}

This code just sets up the clock out pin to display the Main System Clock.

I don't think so :rolleyes:

UM:

Quote:

When the CPU clock is selected and is higher than approximately 50 MHz, the output must be divided in order to bring the frequency within the ability of the pin to switch with reasonable logic levels.

Back to you initial problem:

Quote:

My question is why the automatically generated code is failing.

Probably your hardware is failing. Without SystemInit your board isn't using PLL0, so probably your PLL0 setup isn't working :mad: So did you check your crystal already?

Re: Probllem with LPC1769 & CMSIS

lpcware — Thu, 16 Jun 2016 02:32:20 GMT

Content originally posted in LPCWare by jab on Wed Jun 13 11:02:34 MST 2012
The code works because I am using the IRC oscillator (on these chips it is easy to start with that). I had tried to get the UART working but the clock output pin is much simpler.

However you do make a good point about the crystal...I have checked it was oscilating on the crystal pins and it is but it is a 25MHz XTAL and I dont know what the SystemInit function tries to set up. I suppose the core will die if it assumes a lower frequency and the frequency goes out of range.

At least it gives me a place to start. It is silly though because the M0 CMSIS library starts using the IRC and then the user must switch to the other clocks. Why this one switches straight to the external crystal I dont know!

Anyway thanks, I will post if I run into further problems or solve it :-P

Re: Probllem with LPC1769 & CMSIS

lpcware — Thu, 16 Jun 2016 02:32:22 GMT

Content originally posted in LPCWare by Ex-Zero on Wed Jun 13 11:28:09 MST 2012

Quote: jab
...I dont know what the SystemInit function tries to set up...

Defaults: 12MHz crystal is generating 100MHz with

#define PLL0CFG_Val     0x00050063

So you are trying to run your MCU with about 208MHz :eek:

Using:

#define PLL0CFG_Val     0x0005002F

should reduce that to 100MHz again

Re: Probllem with LPC1769 & CMSIS

lpcware — Thu, 16 Jun 2016 02:32:22 GMT

Content originally posted in LPCWare by jab on Wed Jun 13 12:53:34 MST 2012
My that is quite a clock.

They should make the CMSIS library default to use the IRC clock or main crystal without the PLL! (like with the M0 parts).

Oh well at least I know what it is now and it explains why it never got past system init.

Thanks for your help! At least I know to double check what the library does by default in the future and not to assume it uses the internal RC clock.