How to use lpc54608 SDK

[Anonymous]

(moved here from LPCXpresso forum)

I created and downloaded an SDK for the lpc54608 using the MCUXpresso (see Welcome to MCUXpresso | MCUXpresso Config Tools ) and got it to work with LPCXpresso.

This means I can now create/download and debug code on my LPCXpresso54608 board and one of the first things I tried is a simple blinky using the systick but I had a little problem getting the GPIO port to work.

I used the fsl_gpio driver provided, the GPIO port was configured using:

#define USER_LED_1_PORT  3
#define USER_LED_1_PIN  14

    /* Define the init structure for the output LED pin*/
    gpio_pin_config_t led_config = {
        kGPIO_DigitalOutput, 0,

    };

    /* Init output LED GPIO. */

    GPIO_PinInit(GPIO, USER_LED_1_PORT, USER_LED_1_PIN, &led_config);
    GPIO_WritePinOutput(GPIO, USER_LED_1_PORT, USER_LED_1_PIN, 0);

and GPIO_WritePinOutput was used in the SysTick_Handler to toggle the GPIO pin.

Unfortunately this did not work. SYSCON->AHBCLKCTRL[0] |= (1<<17) needs to be added in order to enable the clock to GPIO3.

The lpc54608 user manual clearly mentions this in the "Basic configuration" chapter but I cound not find this in the SDK documentation. After browsing through the examples I noticed there is a non-documented CLOCK_EnableClock() function to do this. The example in the SDK documentation does not use this function but does contain a reference to a Board_InitHardware() function that is not documented.

So currently I need the SDK documentation, example programs and the user manual to get even basic functions to work.

I think that enabling/disabling clocks for a peripheral should be part of the driver. If not, any additional initialization that needs to be done before using a peripheral should be clearly documented.

How mature will the SDK be? Is it supposed to be usable for (commercial) projects, do we have any influence on the content for the different drivers? Is there, or will there be, a bug report system to log problems like this and get them solved in a new release?

Regards,

Rob

[bin_er]

Hi Rob,

LPC Application team also notice the undocumented GPIO clock enable, and inform SDK team to add a comment to GPIO_PinInit function to remind user to enable clock for GPIO.

For LPC5460x, there is no LPCOPEN any more, only SDK. Anyway, SDK is improving. As far as I understand, quite some bugs are solved in new release.

Bin

[Anonymous]

Hi Bin,

thanks, good to see improvements being made.

In general the SDK looks good - at least as a starting point for our own development. I am now testing the different peripherals I need and I now have GPIO, UART and the system clocking (SYSPLL) running.

Unfortunately there are no sources for the power.lib. That means that (for lpcxpresso) I need to figure out what the function in that library do the hard way.

For most peripherals this is not a big problem since the user manual contains a very nice step by step instruction in the "Basic configuration" chapter. I found that to work very well.

The System PLL (part of SYSCON) does not have this so it took me some time to figure out that POWER_SetPLL()  is only used to clear the kPDRUNCFG_PD_VD3 bit (bit 26) in the PDRUNCFG register.

By the way; it looks strange to see that the drivers do mange the power configuration but don't enable the clocks themselves. Do you know of any reason why this is done this way?

Anyway, SDK is improving. As far as I understand, quite some bugs are solved in new release.

How do we know there is a new release of the SDK? Do I automatically get an email when I have an MCUXpresso configuration for this chip or do I need to check this by hand?

[bin_er]

Hi Rob,

The power library in library format is because

When user apply low power mode, it need to switch off some power gating, and the sequence is fixed and we don't want user to change it. You know the wrong operation on internal regulator and power gating may damage the chips, so the power library is in binary format.

The power library should have a header file to elaborate the API of it

By the way; it looks strange to see that the drivers do mange the power configuration but don't enable the clocks themselves. Do you know of any reason why this is done this way?

I may not understand fully, can you have an example?

For the new release, as a user, I ever got a mail for that

[Anonymous]

Hi Bin,

You know the wrong operation on internal regulator and power gating may damage the chips, so the power library is in binary format.

That might make some sense, but this limits the use of the power.lib to compiler environments provided by NXP.

Not having the power.lib source code means that I need to write some functions myself and that only makes the chance of making mistakes bigger ...

I just noticed the new release of the user manual (Rev 1.2 - 24 February 2017) contains a separate chapter for the power control API.

By the way; it looks strange to see that the drivers do mange the power configuration but don't enable the clocks themselves. Do you know of any reason why this is done this way?

I may not understand fully, can you have an example?

I noticed this while working on the PLL. fsl_clock.c and fsl_utick.c have some functions that control the power themselves. But apparently only those files do this.

As an example:

fsl_clock.c:

pll_error_t CLOCK_SetPLLFreq(const pll_setup_t *pSetup) {     /* Enable power VD3 for PLLs */     POWER_SetPLL();     /* Power off PLL during setup changes */     POWER_EnablePD(kPDRUNCFG_PD_SYS_PLL0);    /* Write PLL setup data */     ...    /* Flags for lock or power on */     if ((pSetup->flags & (PLL_SETUPFLAG_POWERUP | PLL_SETUPFLAG_WAITLOCK)) != 0)     {         ...        /* Enable peripheral states by setting low */         SYSCON->PDRUNCFGCLR[0] = SYSCON_PDRUNCFG_PDEN_SYS_PLL_MASK;     }     ...    return kStatus_PLL_Success; }

The function begins with POWER_SetPLL() and POWER_EnablePD() to enable Vd3 to the PLLs and disabling power to the system PLL, then it programs the PLL and enables the power by writing directly to PDRUNCFGCLR[0].

Apart from the fact that two different methods are used to write to bit 22 in PDRUNCFG (first by calling POWER_EnablePD() and later by writing to PDRUNCFGCLR) this does make sense to prevent eratic power behavior due to CCO jitter.

But if I want to use the ADC, I need to clear the respective bits in SYSCON->PDRUNCFG[0] myself before using the ADC.

As a side note, the SYSCON_PDRUNCFG_PDEN_SYS_PLL_... defines are strange:

LPC54608.h
#define SYSCON_PDRUNCFG_PDEN_SYS_PLL_MASK        (0x400000U) #define SYSCON_PDRUNCFG_PDEN_SYS_PLL_SHIFT       (22U) #define SYSCON_PDRUNCFG_PDEN_SYS_PLL(x)          (((uint32_t)(((uint32_t)(x)) << \      SYSCON_PDRUNCFG_PDEN_SYS_PLL_SHIFT)) & SYSCON_PDRUNCFG_PDEN_SYS_PLL_MASK)

The 0x400000 must always match 1<<22.

I found more of those little bits but I think it's best to leave these as-is and wait for the new SDK release.

For the new release, as a user, I ever got a mail for that

Good to know. I am a front line developer and working with new chips means that it takes time to get the development boards, chip samples, documentation and programming tools.

It's good to see that NXP is focussing on this too. Updates on user manual and SDK are highly appreciated :smileyhappy:

Regards,

Rob

[bin_er]

Hi Rob,

As to power library, it should be in 3 formats for either MCUXPRESSO SDK, IAR or KEIL in LPC5411x by your configuration. Are you mean to use the library besides these three common ones?

As to kPDRUNCFG_PD_VD3....

It is really good feedback.

#define SYSCON_PDRUNCFG_PDEN_SYS_PLL(x)          (((uint32_t)(((uint32_t)(x)) << \

     SYSCON_PDRUNCFG_PDEN_SYS_PLL_SHIFT)) & SYSCON_PDRUNCFG_PDEN_SYS_PLL_MASK)

The x should be either 0 or 1. I guess it is for better reading.

it might be easy to misuse. what is your idea?

As to ADC , I agree with you. the clock and power gating should be correctly configured by module API function regardless the default value of the configuration.

[Anonymous]

I would do something like:

#define SYSCON_PDRUNCFG_PDEN_SYS_PLL(x)  (uint32_t) ((x) & 1) << SYSCON_PDRUNCFG_PDEN_SYS_PLL_BITNUM)

In this case you don't need the _MASK macro at all - and note BITNUM in stead of _SHIFT (the meaning of the define is the bit number in the register, shift is the operation used to get the bit at the correct place).

Using the _MASK only makes sense when using multiple bits, but all macros use just one bit.

Furthermore you could debate about the use of enable/disable and even use POWER_Enable() instead of POWER_DisablePD(). I had to read POWER_DisablePD(kPDRUNCFG_PD_SYS_PLL0) twice to see this enables the power to the PLL.