[question]lpc54608 runs to hardfault when flashed lpc54628's nsh example.

[kxjiang]

hi, all. I have seen that Nuttx has official support for LPCXpress-LPC54628 board from NXP, but what I have is LPC54608 board. From datasheet of LPC546xx, we know that LPC54608 and LPC54628 are almost the same, except LPC54628 has CAN-FD & SHA while LPC54608 does not. And LPC546428 can run up to 220MHz while LPC54608 runs up to 180MHz. 

So I just flash the official nsh demo of LPC54628 on my LPC546O8 board. But it runs to hardfault after printing the shell prompt. Here is the log print:

NuttShell (NSH)

nsh> <ESC>[Kup_hardfault: PANIC!!! Hard fault: 40000000

up_assert: Assertion failed at file:armv7-m/up_hardfault.c line: 171

up_dumpstate: sp:     20000bb0

up_dumpstate: IRQ stack:

up_dumpstate:   base: 20000c00

up_dumpstate:   size: 00000800

up_stackdump: 20000ba0: 20000c00 200016b4 00000400 00000d27 000000ab 20000bd0 20000bd0 00003095

up_stackdump: 20000bc0: 00000000 20000bd0 00000bfd 00012d09 00000000 00000c05 00000bc5 20000dd8

up_stackdump: 20000be0: 00000003 00000bb1 00000000 2000164c 20000df4 00000003 00000000 000009f1

up_dumpstate: sp:     20001698

up_dumpstate: User stack:

up_dumpstate:   base: 200016b4

up_dumpstate:   size: 00000400

up_stackdump: 20001680: 20002390 20000e9c 00000000 000010e0 000010e0 40000200 000010c9 200016b8

up_stackdump: 200016a0: 00026948 12345678 00000159 00000000 03000cab 00000000 00000000 00000000

up_registerdump: R0: 00000000 00000c80 20002390 20000e9c 20000c00 20000df4 00000003 00000000

up_registerdump: R8: 00000000 00000000 00000000 00000000 00000000 20001698 000010e0 000010e0

up_registerdump: xPSR: 40000200 PRIMASK: 00000000 CONTROL: 00000000

up_registerdump: EXC_RETURN: fffffff9

 I have done some test on this. It looks like something wrong in the 

readline_common(&vtbl.vtbl, buf, buflen)

function, or 

uart_read(FAR struct file *filep, FAR char *buffer, size_t buflen)

since readline_common actually calls uart_read.

I don't know why LPC54608 crashes since it's the same as LPC54628. Any suggestions on this problem? Thanks!

The map of the Nuttx binary file is attached.

 

[Alan Carvalho de Assis]

Hi kxjiang,

Please take a look at this documentation:

http://nuttx.org/doku.php?id=wiki:howtos:cortexm-hardfault

Also I documented how to use gdb with openocd (and with JLinkGDB) at
my blog: http://acassis.wordpress.com

Using it you can figure out what is happening.

BR,

Alan

> --
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nuttx+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[kxjiang]

Hi, Alan. Thanks for your reply. Actually, I have checked the registors in the dump outputs. But have no clue. I'll look into the doc that you link. By the way, I have read your blog posts long before. They are great and very informative.

The problem is I can only use JLinkGDB to debug since I'm running the test on windows.  I want to use openocd and eclispe both on windows, in that way it may be 

a little easier to trace the code executation. Using objdump to list the assembly code then setting breakpoint using JLinkGDB is sometime annoying. Maybe I'm not 

getting used to it. Thanks for your suggestions again.

在 2018年7月4日星期三 UTC+8下午6:59:36，Alan Carvalho de Assis写道：

[Alan Carvalho de Assis]

Hi kxjiang,

You can use JLink GDB on Windows as well.

I used the Segger Ozone in the past to do low level hw debug, it could
help you case you are not comfortable with GDB and want to use
something more visual.

You need to load the ozone file with the registers mapping of the
LPC54608, then it will identify each bit of the registers.

[patacongo]

 I have done some test on this. It looks like something wrong in the 

readline_common(&vtbl.vtbl, buf, buflen)

function, or 

uart_read(FAR struct file *filep, FAR char *buffer, size_t buflen)

since readline_common actually calls uart_read.

I don't know why LPC54608 crashes since it's the same as LPC54628. Any suggestions on this problem? Thanks!

I doubt that the UART-related functions themselves are the problem, but there may be some correlation between the UART use and the problem:  Perhaps you are getting a stack overlow while using the UART?  Have you tried increasing the stack sizes... including the INTERRUPT_STACK?

[kxjiang]

Hi Gregory,

    Sorry for my late response. Your doubts are correct. The user stack size should be increased. The board will not run to hardfault but still can't receive data from uart. One thing I forgot to check is the clock settings of LPC54608, since it can only run at a maximum frequency of 180Mhz.  so I change the settings in board.h to use 180MHz instead of 220MHz. By doing so, board will fail waitting for locking PLL. See below.  After referring the driver from NXP, we should turn on the ext clock if system pll input select clk_in.  Now the board runs normally. I don't know if LPC54628 has the same problem if chages the clock to 180MHz. 

// #undef  BOARD_180MHz
// #define BOARD_220MHz                    1

#undef   BOARD_220MHz
#define  BOARD_180MHz                    1

static void lpc54_configure_pll(FAR const struct pll_setup_s *pllsetup)

{

  uint32_t regval;

   /* Turn on the ext clock if system pll input select clk_in */

  regval  = getreg32(LPC54_SYSCON_SYSPLLCLKSEL);

  if ((regval & SYSCON_SYSPLLCLKSEL_CLKIN) != 0) 

  {

      putreg32(SYSCON_PDRUNCFG0_VD2ANA, LPC54_SYSCON_PDRUNCFGCLR0);

      putreg32(SYSCON_PDRUNCFG1_SYSOSC, LPC54_SYSCON_PDRUNCFGCLR1);

  }

   ...
   ...

  /* Wait for the lock? */

  if ((pllsetup->pllflags & PLL_SETUPFLAG_WAITLOCK) != 0)

    {

      while ((getreg32(LPC54_SYSCON_SYSPLLSTAT) & SYSCON_SYSPLLSTAT_LOCK) == 0)            <======= stuck here.

        {

        }

    }

}

Thanks your help, and thanks for Alan's advice. The Ozone tool is helpful.

BR.

在 2018年7月4日星期三 UTC+8下午9:41:45，patacongo写道：

[patacongo]

> I don't know if LPC54628 has the same problem if chages the clock to 180MHz. 

We will have to answer that question somehow before we can bring the change in.

[patacongo]

> I don't know if LPC54628 has the same problem if chages the clock to 180MHz. 

We will have to answer that question somehow before we can bring the change in.

Sorry about my typos last in the last email.  It was late here and I was responding with my phone.  I am not good with those little keypads.

After reading the reference manual, these power supplies should definitely be needed in all cases if the external crystal clock is selected.  Perhaps the difference between the LPC54628 and the LPC5408 is that the reset state of the System Clock power is different on these two chips.  Anyway, the LPC54628 is running at 220MHz on a different clock source so this should not cause any problems now.

This makes me wonder:  If a different clock source is selected (such as if the board were to go into a lower power mode), should the power to the Ssystem Clock be disabled?  That might be important if you are trying to achieve low power consumption but I don't know enough.  So currently, if power to the System Clock is enabled, then it stays enabled forever.

Here is the commit.  I did move the logic to just where the clock source is selected.  That makes it easier to follow what it is doing, I think.  I also added a lot of comments mostly to help me understand what is happening.

commit 70dc642da33b7015c202073cdc66cca8e356f5f7
Author: kxjiang <kxji...@gmail.com>
Date:   Sun Jul 8 06:58:14 2018 -0600

    The LPC54608 can only run at a maximum frequency of 180Mhz.  This configuration requires uses the clk_in, external crystal clock, to drive the PLL.  When that input was selected, the board bootup failed waiting for the PLL to lock.  After referring the driver from NXP, we should turn on power sources for the ext clock if system pll input select clk_in.  NOTE that the LPC54628 did not require this step... perhaps because the system oscillator power was already enabled.

Thanks,

Greg

[kxjiang]

Hi Greg,

Thanks for your detailed description and code correction for better readability. 

As for the power managment of LPC54xx, since many moudle's clock is very independent. It may be reasonable to power off the unused clocks as you mentioned.

Here's a power mode example from NXP[group__power]. 

int main(void)

{

   /* Init board hardware. */

   BOARD_InitHardware();

   /* Running FRO = 12 MHz*/

   BOARD_BootClockVLPR();

   /* Init output LED GPIO. */

   LED_GREEN_INIT(1);

   /* Attach Main Clock as CLKOUT */

   CLOCK_AttachClk(kMAIN_CLK_to_CLKOUT);

   /* Set the clock dividor to divide by 2*/

   CLOCK_SetClkDiv(kCLOCK_DivClkOut, 2, false);

   /* Intiialize UTICK */

   UTICK_Init(UTICK0);

   /* Set the UTICK timer to wake up the device from reduced power mode */

   UTICK_SetTick(UTICK0, kUTICK_Repeat, UTICK_TIME, NULL);

   /* Enter Deep Sleep mode */

   POWER_EnterDeepSleep(SYSCON_PDRUNCFG_PDEN_SRAM0_MASK | SYSCON_PDRUNCFG_PDEN_SRAMX_MASK | SYSCON_PDRUNCFG_PDEN_WDT_OSC_MASK);

   /* Set the clock dividor to divide by 1*/

   CLOCK_SetClkDiv(kCLOCK_DivClkOut, 1, false);

   while (1)

   {

       /* Toggle LED */

       LED_GREEN_TOGGLE();

       delay();

   }

}

the function POWER_EnterDeepSleep is called with less block powered on(SRAM, WDT). The power of other blocks such as FRO might be powered off.

NXP does not provide the source code of power management api. All related funtions are provided in a lib. Can we dive into te disassembly to make sure that power of

unrelated clocks are powered off? Or may there be a better way to test?

Here's a ref about clocks and power management of LPC54xx, same as the user manual but might be more concise.

BR.

在 2018年7月8日星期日 UTC+8下午9:10:06，patacongo写道：