LPC18xx and LPC43xx LPCOpen v2.12 packages released

[lpcware]

Content originally posted in LPCWare by NXP_Support on Fri May 16 10:35:12 MST 2014

A new LPCOpen Version 2.12 for boards using LPC18xx and LPC43xx MCUs, available <a href="http://www.lpcware.com/content/nxpfile/lpcopen-platform">here</a>.

For change log please visit the <a href="http://www.lpcware.com/content/project/lpcopen-software-development-platform-nxp-lpc-microcontroller...">History page</a>.

[lpcware]

Content originally posted in LPCWare by dmitriyf on Wed Oct 08 11:18:05 MST 2014
Hello everyone,
I'm new to LPCware and found it very confusing. There is no documentation how to build projects.
It only says "download, install, and it will build".
No it does not build.
I'm using IAR (besides no requirement for IAR version, 6.40 chocks on parameters) and LPC4337.

First of all, where comes definition of board from? How do I define a board?
I see no include directories in IAR project. Should I define myself manually?

What should I define for running double core CORE_M4 or CORE_M0.
No explanation, no documentation. Seems everybody knows everything and there is no need to document.

I have Waveshare Open4337-C board and their examples work. But they have no double core example.
That was main reason to evaluate NXP product, which seems good, but examples and documentation
not up to STM32 we are using right now.

Too many questions, too many unknowns.. Do not know where to dig and how to build product.
Is there configuration tool to configure for the board?

[lpcware]

Content originally posted in LPCWare by rockyh on Thu Aug 28 10:19:36 MST 2014
It is a mystery to me why on Hitex 4350 board that clock setup with lpcopen 2.12 appears to work. On our custom board, 2.12 does not, and the code must be modified to match the description in the users guide.  Our board uses the LPC4330, which should be the same, but perhaps there is something different.
I am trying to debug a rather peculiar bug on our USB0 port, and I have to wonder if it is something else with clock setup that is not compatible. (The same USB code works on Hitex, but not on our board).  Could be something unrelated, however.

[dmarples]

This does not appear to be fixed in V2.20 that was just released a few days ago??

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Aug 28 02:20:26 MST 2014
Hi Pierre,

as you have also discovered, the PLL setup code in 2.12 has some issues.
I have given up on fixing it within the original files, since I feel any rework may break some other functions or libraries.

I have instead rewritten the function  Chip_Clock_SetupMainPLL by Chip_Clock_SetupMainPLL_mch and now call it directly from my application:

    
       // set PLL1 frequency directly (crystal osc. must be already enabled and running)
       Chip_Clock_SetupMainPLL_mch(CLKIN_CRYSTAL,100000000);
// update clock variable
SystemCoreClockUpdate();

This works for me for all frequencies I have tested so far, both below and above 110 MHz.

/* Directly set the PLL1 frequency
 *
 * Input Clock is divided by 3 to obtain a finer range.
 * For 12MHz crystal we can thus get CCO frequencies that are a multiple of 4 in the range from 156 to 320 MHz.
 * This is important if Ethernet is used, because we want to have a 50 MHz clkout signal for the PHY chip.
 * We can derive that frequency if we use 50/100/150/200 MHz as the PLL1 output clock.
 */

uint32_t Chip_Clock_SetupMainPLL_mch(CHIP_CGU_CLKIN_T Input, uint32_t fout)
{
volatile uint32_t delay = 250;
uint32_t PLL1Reg, cco, msel, nsel = 2, psel;
uint32_t fin = Chip_Clock_GetClockInputHz(Input)/(nsel+1);


// sanity checks
if ((fout>204000000) || (fout <10000000)) return 0;

// determine required postscaler
cco=fout;
psel=0;
if (fout < 156000000)
{
cco*=2;
for (; cco<156000000; cco*=2)
{
psel++;
}
}
// determine M
msel=cco/fin-1;

// now set up new loop parameters without direct mode on
PLL1Reg = (Input << 24) | (msel << 16) | (nsel << 12) | (1 << 11) | (psel << 8);
LPC_CGU->PLL1_CTRL = PLL1Reg;

// wait until PLL1 has locked
while (!Chip_Clock_MainPLLLocked());

// if f>156 MHz use direct output (no postscaler)
if (fout > 156000000)
{
PLL1Reg |= (1<<7);
LPC_CGU->PLL1_CTRL = PLL1Reg;
}

/* Wait for 50uSec */
while(delay--) {}

return Chip_Clock_GetMainPLLHz();
}

Of course the crystal oscillator must be running before calling the function.
I have also included the 50us wait at the end, although I think it's not necessary.
The PLL has already locked at this point.
It might, however, have been suggested by the chip designers to avoid negative effects of a sudden power surge when switching the whole chip from very low to very high frequencies.
If so, I should have placed the wait before going above 156 MHz.
Only NXP knows why to wait.


I really hope this will be fixed in 2.13, I don't like to have to maintain separate functions.

Regards,

Mike

[lpcware]

Content originally posted in LPCWare by pierre on Thu Aug 28 01:06:35 MST 2014
There are still some issues...

In LPX4330 Xplorer board_sysinit.c, function Board_SetupClocking() :

Chip_SetupCoreClock(CLKIN_CRYSTAL, MAX_CLOCK_FREQ, true);

If i set it to CLKIN_IRC, it works.
If I set it to crystal, it does not work, the cpu stops responding even to JTAG. Then I have to use the boot mode switches to prevent it to boot from SPIFI and execute the offending code in order to use LPC-Link to reflash a working code (which uses the IRC oscillator).

This is a symptom of incorrect clock initialization I guess. Maybe it doesn't wait enough for the oscillator to start ?...

However, after booting on the IRC oscillator, if I put "Chip_SetupCoreClock(CLKIN_CRYSTAL, MAX_CLOCK_FREQ, true);" in main(), then, it works. This is quite bizarre. Does it actually use the XTAL or the IRC, I wonder...

Also, I'd like to use a lower clock frequency to consume less power. If I replace MAX_CLOCK_FREQ with 120 MHz, it works, and the frequency seems to be correct. With a frequency below 110000000, it does not work : depending on the values, either the cpu freezes, or it kind of works but the UART output is garbled. I think it is because of this line in lpcopen sysinit_18xx_43xx.c / Chip_SetupCoreClock() :

if (core_freq > 110000000UL)

It configures the PLL differently depending on the frequency.

However it only wants to go up : the code is there to go from the default (low) boot frequency to 204 MHz, but the code is not there to go the other way around !...

So, I change Board_SetupClocking to startup at 96 MHz. No more problems. Except the UART stops working, probably because it uses the wrong baud rate (which should be set automatically by Chip_UART_SetBaud() according to the CPU freq but it seems it is not...

Hm...

[lpcware]

Content originally posted in LPCWare by mch0 on Tue Aug 19 04:25:09 MST 2014
For the upcoming V2.13 release I suggest a correction in function

uint32_t Chip_Clock_GetMainPLLHz(void)

in file

clock_18xx_43xx.c.

The last line is now: return (m / (2 * p)) * (freq / n);
I suggest instead:    return (m * freq) / (2 * p * n);

Mathematically both are equivalent, but the current line runs into integer rounding problems.
This can give wrong results.
Example: m=55, p=1, freq=12000000, n=3
The chip runs at 110 MHz, the original line says 108 MHz.
Since this function is also called by SystemCoreClockUpdate() I think it can be critical.

I'll rework my earlier fix for PLL1 frequency change function, at this point use at your own risk.

Mike

[lpcware]

Content originally posted in LPCWare by rockyh on Wed Jul 30 08:10:24 MST 2014
thank you, mch0.  Yes, the lpcOpen 2.12 clock setup is flawed. Not even sure how/why it was able to work on the Hitex board. (and now that I think about it, maybe it wasn't working).

[lpcware]

Content originally posted in LPCWare by pierre on Tue Jul 29 06:40:45 MST 2014
Your fix saved my day :bigsmile:

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Jun 20 22:49:30 MST 2014
Hi Dan,

maybe you can use my temporary fix (see attachment to the other post in the 43xx forum).
I have not delved deeper into this, because it works for me at this point and I'll replace/delete my code when V2.13 is released with a fix.

Mike

[lpcware]

Content originally posted in LPCWare by Digital Dan on Fri Jun 20 18:59:14 MST 2014
I am also experiencing the PLL1 issue in v2.12.

I seem to have narrowed down the issue to the "Chip_SetupCoreClock" function of "sysinit_18xx_43xx.c".


Setup: MCB4350 (Hardware v1.2), IAR EWARM v7.20, I-Jet v4.2

[lpcware]

Content originally posted in LPCWare by sundarapandian on Wed Jun 11 17:56:26 MST 2014
Hello Mike,
       Thank you for notifying us, we will analyze the problem and make a fix (if required) in the next release.

[lpcware]

Content originally posted in LPCWare by mch0 on Sun Jun 01 05:45:35 MST 2014
Back again, sorry for the delay.
I think I've hit a bug in the code that sets up the PLL1 frequency. Since I'm a HW guy I originally posted in the LPC43xx forum, Title "Glitch in PLL1 source code"

But actually it's an LPCOpen issue, so probably I should have replied here - I discovered this forum a bit late ...

In short the supplied code crashes my LPCLink2 board reliably and it will most probably crash any system under the same circumstances.

Mike