LPC4350 CMSIS Library or LPCOpen

[lpcware]

Content originally posted in LPCWare by gregd on Sat Nov 24 21:30:14 MST 2012
I have been working with the LPC4350 using the CMSIS library, lwip, and FreeRTOS for about a year now.  I am using the IAR development tools.  This development is for a product that we plan to be supporting and adding new features for many years to come.  I am now getting ready implement USB in my application.  I was going to just start with the NXPUSBlib but I saw the new LPCOpen platform so I downloaded it to take a look.  I see that Chip and IP layers completely replace the CMSIS library.  I also noticed that the lwip code has been updated to fit the new framework.  My question is whether I should go ahead and switch everything to the new LPCOpen platform or continue with the separate (older???) libraries?  Will the NXP development efforts continue in both directions or will future efforts be concentrated on the LPCOpen platform? 

What are the benefits and drawbacks of each choice?

Are there plans to add the LPCOpen source code into the sw.lpcware.com repository.  

Thanks,
Greg Dunn

[lpcware]

Content originally posted in LPCWare by wellsk on Thu Nov 29 17:43:00 MST 2012
>- Note: For all toolchains and SPIFI and Parallel Flash configurations,
>this example is dependent on a custom linker script file to place
>memory setup routines in internal SRAM.
This doesn't apply to LPCOpen code and the examples current use the default link map for each toolchain running the clock and other drivers in either internal or SPI FLASH without relocation. All the examples use all of the drivers in FLASH. (However, there are some complex examples - mostly dual core examples or custom examples - in LPCOpen that do use custom scatter scripts for the M0 image placement.)

>I also remember at one point I was having issues with some of the startup code being located in memory that was using address lines above A13 which are not initialized by the boot ROM. Anyway, I'm sure you all are addressing these issues and it will be nice not to have to relocate code into RAM.
All the examples currently boot from sources that this won't really apply to (SPI or internal FLASH). The default startup code in LPCOpen doesn't configure these lines early on - the examples for Hitex and Keil configure address pins as part of SystemInit(), while the NGX board doesn't configure them at all (no external memory). That being said, the Hitex examples in the LPCopen platform use SPI FLASH, not NOR FLASH, so the details have been worked out yet. I guess the easiest fix would be to put the mux setup as part of the startup code and make sure the startup code that initializes the address muxing is right after the vector table and no leaf functions are called before muxing.

> CGU_UpdateClock() is called which updates the CGU_ClockSourceFrequency structure with all configured clock rates
>Are you reading clock rates by interpreting from processor registers now instead of storing in memory structures?
The LPCOpen 18xx/43xx clock driver is stateless, doesn't have an 'init' function., and doesn't use any RW data. All 'get' functions of the driver use only register states to determine the result. Currently, all clock setup is done as part of the M4 core bootup. You can use the peripheral clock enable/disable/getrate functions on both cores and they won't interfere with each other. But this still doesn't mean the clock driver is 100% multi-core safe - setting up and altering the PLL and base clocks (vs individual peripheral clocks) at run-time on both cores wouldn't be a good thing.

[lpcware]

Content originally posted in LPCWare by mark03 on Thu Nov 29 16:49:25 MST 2012
Out of curiosity, is one of these library packages recommended above another for those of us using free toolchains (GCC and Eclipse)?  I haven't set mine up yet so this question is somewhat out of ignorance.

[lpcware]

Content originally posted in LPCWare by gregd on Thu Nov 29 14:28:34 MST 2012
Thank you so much for your detailed response!

It has been quite a while ago since I was really working on the boot up portions of my application but as far as I remember, I was having problems with the code running from static CS0 flash while either updating the clocks/PLLs to run at 204MHz or initializing the external CS0 EMC memory.  If you look at the abstract.txt file in \lpc43xx\Examples\BOOTFAST\Fast_Gpio_LedBlinky you can see the following note:

  - Note: For all toolchains and SPIFI and Parallel Flash configurations,
          this example is dependent on a custom linker script file to place
          memory setup routines in internal SRAM.

I also remember at one point I was having issues with some of the startup code being located in memory that was using address lines above A13 which are not initialized by the boot ROM.  Anyway, I'm sure you all are addressing these issues and it will be nice not to have to relocate code into RAM.


One other issue that I would be interested in how you plan to handle is related to dual core applications.  My main M4 app configures most of the clocks etc..  CGU_UpdateClock() is called which updates the CGU_ClockSourceFrequency structure with all configured clock rates.  I configured the linker to locate the CGU_ClockSourceFrequency structure at the same location in internal RAM for both the M4 and M0 applications.  This way, after the initial M4 startup, the M0 app is exectued.  It can then use functions for things like setting the UART baud rate and have them work correctly because they depend on the clock values to be correct.  What approach do you recommend for this with LPCOpen.  Are you reading clock rates by interpreting from processor registers now instead of storing in memory structures?

Thanks,
Greg Dunn

[lpcware]

Content originally posted in LPCWare by wellsk on Thu Nov 29 11:00:00 MST 2012
>I compiled the USBMassStorageHost project to work on USB1. In doing this, the baud rate initialization for the debug port UART0 didn't work properly. The USB_init routine was called after the debug UART was initialized. I believe the issue was where the USB changes the operating frequency to 180 MHz. After the normal initialization I believe it was at 204 MHz when the UART init was called. I moved the UART init afterwards and it worked fine.
We know about this issue and it will be corrected in the next release. If you do catch more issues, it doesn't hurt to add the tracker issue for it. (Tracker issues will eventually get processed, although they have been somewhat delayed lately, and you should get an email when it's status has changed if you subscribe to that issue).

>One other comment/question: In my application using IAR with the older CMSIS files for LPC4350, I am loading the EMC, CGU and maybe another file or two into internal SRAM. This is required during the EMC initialization. The other CMSIS library files are still located in external flash memory. Is there any standard features planned with LPCOpen to support this or do I just need to set custom compile/link options for the particular C library files as I did with the old CMSIS library?
I can probably answer this question, but might need to know why those files needed to be relocated to IRAM. Is it because they use RW data areas that are not initialized for those drivers, but you need to use that data to initialize the ENC itself? (so it's using a resource that isn't yet available).

Changes have been made to the low drivers and setup code in LPCOpen. The clock, EMC setup (DRAM), and pin muxing are performed prior to calling the application entry point (main, __main, iar_entry, etc.). Setting up DRAM or external memory prior to doing this allows scatter loading, per-initialized data copy to DRAM, and ZI data section clear in DRAM/extmem to work correctly as part of the toolchain's run-time setup. So you can use the CGU driver, EMC driver, and some other low level drivers without them trying to use external memory for data storage prior to it being initialized.
Most driver code and startup code in the LPCOpen platform are/were checked to verify they don't use RW/ZI memory, so the use of EMC, CGU, and most drivers can be safely used prior to memory being setup. Not all drivers have this features, some do require memory (ie, UART) - these need to be setup as part of the application after memory is initialized. Some drivers (ie, CGU/CCU) are also stateless and can be used on all cores in the multi-core parts simultaneously without them altering what's on the other core. Currently, not all drivers are 'multi-core friendly' yet, but they will be soon - with the exception of setup related drivers (ie, DRAM setup which is done only one on the core that boots the system).

So you should no longer need to locate the CGU and EMC drivers to IRAM to use them.

On another note, you had asked about ongoing LWIP support in another email. LWIP will be maintained in both the LPCOpen platform and the older lwip_lpc release until the LPCOpen platform has all the current support of the lwip_lpc release (this will be the case with other packages too). Currently, the LPCOpen port and the lwip_lpc port have the same functionality for LWIP on the 18xx/43xx, but the LPCOpen port has different standards applies to that port and uses LPCOpen resources. Once the 17xx support for LWIP makes it into the LPCOpen platform, the lwip_lpc port will no longer be actively developed.

[lpcware]

Content originally posted in LPCWare by gregd on Wed Nov 28 16:57:25 MST 2012
Thank you for your response.  That sounds like a very good plan.  I have played around with the NXPUSBlib IAR examples for LPCOpen, they seem to be very well organized.  Just a few comments:

I compiled the USBMassStorageHost project to work on USB1.  In doing this, the baud rate initialization for the debug port UART0 didn't work properly.  The USB_init routine was called after the debug UART was initialized.  I believe the issue was where the USB changes the operating frequency to 180 MHz.  After the normal initialization I believe it was at 204 MHz when the UART init was called.  I moved the UART init afterwards and it worked fine.

One other comment/question:  In my application using IAR with the older CMSIS files for LPC4350, I am loading the EMC, CGU and maybe another file or two into internal SRAM.  This is required during the EMC initialization.  The other CMSIS library files are still located in external flash memory.  Is there any standard features planned with LPCOpen to support this or do I just need to set custom compile/link options for the particular C library files as I did with the old CMSIS library?

Thanks,
Greg

[lpcware]

Content originally posted in LPCWare by nxp21346 on Wed Nov 28 15:14:05 MST 2012
Hi!

The LPCOpen Platform libraries contain the CMSIS functionality and much more such as hooks to the emWin GUI, nxpUSBLib, and LWIP. They are not compatible with the older PDL libraries. Currently, we are focusing a lot of development effort on supporting LPCOpen Platform on higher-end parts such as the M3/M4 products. Currently the LPCOpen Platform supports Keil and LPCXpresso, but more tool support is coming soon.

If you are able to transition to the LPCOpen Platform, (once IAR support is integrated) it should make it easier to build a real system that combines several libraries together such as USB and Ethernet. Finally, we are investing in code quality in the LPCOpen Platform with mandatory code reviews of each change and extensive testing before each release. This is why the code is not available "real-time" in the sw.lpcware.com repository.

-Dave @ NXP