topic Re: LPC4370 board bootstrapping problems in LPC Microcontrollers

LPC4370 board bootstrapping problems

omegahacker — Mon, 08 May 2017 21:48:17 GMT

Due to the utter lack of any LPC4370 breakout boards (the LPC-Link2 + LabTool gives me a ridiculously tiny number of pins), I was forced to design and fabricate my own breakout. I've attached a picture and the Eagle (7.x) schematic for it for reference. I've been trying to narrow down what's going on, but running into some very strange things.

First off, when I try to load my normal project, I get an error saying that the SPIFI flash is "unsupported". I have a IS25LP080D on my board instead of the Winbond (obsolete) that's on the LPC-Link2. However, that's not where I'm stuck right now. I suspect that'll be an issue next...

At the moment, I'm running a test program that doesn't touch the flash, and it's hard faulting in the clock setup code, in a somewhat non-deterministic way. I'll either get:

0x10322002
<signal handler called>() at 0xfffffff1
0x184
Chip_Clock_SetupMainPLLMult() at clock_18xx_43xx.c:222
Chip_Clock_SetupMainPLLHz() at clock_18xx_43xx.c:176
....

HardFault_Handler() at cr_startup_lpc43xx.c:459
<signal handler called>() at 0xfffffff1
Chip_Clock_SetupMainPLLMult() at clock_18xx_43xx.c:222
0x6766e72

bss_init() at cr_startup_lpc43xx.c:288
<signal handler called>() at 0xffffff1
0x27ac
0xc8933f14

However, if I set a breakpoint at Chip_SetupCoreClock() at sysinit_18xx_43xx.c:97 on a call to Chip_Clock_SetupMainPLLHz(), then resume from there, the chip works just fine at least to the test code that toggles a pin.

I need to get these boards going so I can continue with my work, does anybody have any ideas what on earth might be happening here???

Original Attachment has been moved to: lpc4370-breakout.sch.zip

Re: LPC4370 board bootstrapping problems

jeremyzhou — Wed, 10 May 2017 07:56:27 GMT

Hi Erik Walthinsen,

Thank you for your interest in NXP Semiconductor products and the opportunity to serve you.

I've gone through the shared sch, and compare with the sch of the LPC-Link 2, I find that they is almost look alike except the external SPI flash.

So I consider the demos which are from the LPCOpen are definitely able to run on your board if relocates the demo in the internal RAM during debugging.

I was wondering if you can exemplify the details steps to replicate the issue, I think it can help me to figure out the root cause of the issue.
Have a great day,
TIC

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: LPC4370 board bootstrapping problems

omegahacker — Wed, 10 May 2017 15:31:44 GMT

I'm curious what's different about the SPIFI besides the part number? I doublechecked every pin several times, so I'm 99% sure I have the schematic correct. The only difference I'm aware of is the part number, which turns out to be fatal because none of the stock .cfx drivers will write to that flash, as it has a type/size of 0x6014 instead of the 0x4014 of the Winbond chip. I've ordered some W25Q80DV chips to swap in and see if that solves the issue.

As far as the startup issue goes, I am literally creating an empty project. M4 standalone, don't add the flash region, compile and run. I'm doing it with the LPC-Link2 providing power over the JTAG cable, but get identical results when powering the board directly from a bench supply.

At this point I have worked around the issue by inserting a delay {for (volatile int i=0;i<100000;i++) ;} around the sysinint.c:97 call to Chip_Clock_SetupMainPLLHz(). This is *not* a viable long-term fix because it results in a noticeable boot delay, but is good enough for now, and ironically is approximate offset by the speed gain of not writing flash...

Re: LPC4370 board bootstrapping problems

jeremyzhou — Thu, 11 May 2017 07:40:13 GMT

Hi Erik Walthinsen,

Thanks for your reply.

The Table 25 has exemplified the supported QSPI flash devices, otherwise MCU fail to boot from any unsupported devices.

Have a great day,
TIC

Re: LPC4370 board bootstrapping problems

omegahacker — Thu, 11 May 2017 15:56:02 GMT

As I stated above I've ordered replacement SPIFI parts and will deal with that issue when they arrive.

However, this is irrelevant to the primary problem, which is that with stock code the chip refuses to boot. Even with the delays I've added as per my previous reply I will still get periodic boot fails.

More pressingly, the 24hr delays induced by this forum, and the 48hr delays induced by address the wrong issue, are causing major problems with my schedule. As requested in the private ticket, I would like to be put directly in touch with an FAE in my general area/timezone in order to resolve this issue.

Re: LPC4370 board bootstrapping problems

omegahacker — Thu, 11 May 2017 16:13:36 GMT

While originally using the LPC-Link2 as a target, I would periodically (15-20% of the time) attempt to start the program and end up on a HardFault. Now that I think about it, that is almost certainly a manifestation of the same problem that I'm seeing with my own boards. That means that the bug in question is present even on NXP's own boards, which is Not Good.

Re: LPC4370 board bootstrapping problems

omegahacker — Fri, 12 May 2017 06:23:26 GMT

Not to distract from the original question, which is why this board cannot start up properly with stock code, but replacing the SPIFI with the W25Q80DV results in what appears to be a successful write to the flash, but random faults with random stack traces throughout user code, with or without the delays around the PLL startup call.

An interesting data point as well is that taking a memory dump (of the main 128KB AHB block) through the Memory Browser goes fairly quickly when an LPC-Link2 is the target, but is significantly slower against my board. That points to an issue of some kind with the JTAG/SWD interface.

Also, pertaining to the random similar failures on the LPC-Link2 board as target, I remembered that this is actually nothing new, and occurs with equal regularity when developing against an LPCxpresso 1549 board. Also to rule out a common factor, it doesn't matter whether the host is Linux or MacOS.

There seems to be a significant problem here with stock boards and tools that is just exacerbated for some reason on my board.

Still waiting to break out of this 24hr forum cycle and talk to a local FAE.

Re: LPC4370 board bootstrapping problems

jeremyzhou — Fri, 12 May 2017 07:11:49 GMT

Hi Erik Walthnsen,

Thanks for your reply.

I was wondering if you can exemplify the detailed steps to replicate the issue when using the LPC-Link2 as a target.

Actually, I've not encountered the any similar issues you demonstrated when I used the LPCOpen library.

About the supporting, you can contact with the local DFAE for checking as online AE can't help you to debug the board in reality.
Have a great day,
TIC

Re: LPC4370 board bootstrapping problems

omegahacker — Fri, 12 May 2017 15:46:51 GMT

This is why I requested contact with an FAE from the very beginning. Yet there is ABSOLUTELY NO INFORMATION about how to get in contact with said FAE. Please provide me with contact information for a west-coast US (Oregon) FAE ASAP.

Re: LPC4370 board bootstrapping problems

jeremyzhou — Mon, 15 May 2017 02:43:51 GMT

Hi Erik Walthnsen,

You can contact with the Distributor FAE via the link, and they will escalate your question to the local FAE.

Hope it helps.

Distributor Network|NXP
Have a great day,
TIC

Re: LPC4370 board bootstrapping problems

GregC — Wed, 17 May 2017 16:35:48 GMT

Hi Erik

I had a quick look to your breakout board for the LPC4370 and it looks really useful to access more MCU signals during the prototyping phase.

I review carefully the thread of your messages exchanged with jeremyzhou

If you you really reproduced the LPC-Link2 routing of the chip and you choosed a QSPI flash supported by our Boot code and SPIFI API, I agree that your board should start successfully...

You couldn't mention much detail about your project online, it is understandable... but let's try to connect you with a local FAE to better support your development.

As suggested by Jeremy, the right point of contact will be our local distributor.
The distributors below have facilities in Portland and certainly distributor FAEs specialized in NXP Semiconductor, who will be able visit you and review your design as well as your code. If needed they will work hand to hand with the local NXP FAEs to resolve as fast as possible your issue with our silicon.

Arrow Electronics
433 NW 4th Avenue
Portland, OR 97209
503-450-1355

Avnet
10260 Sw Greenberg Rd, Suite 400
Portland, OR 97223
503-452-6911

Future Electronics
6650 SW Redwood Lane, Suite 365
Portland, OR 97224
503-603-0956

Please keep us informed with your progress
Greg

Re: LPC4370 board bootstrapping problems

danstahlke — Sun, 14 Jan 2018 02:29:48 GMT

I realize this discussion is fairly old, but in case you are still working on this problem: the clock setup code from lpcopen is buggy. For me, SPIFI boot was okay (most of the time) but running init code from RAM caused a crash. Probably the setup code was more likely to work from SPIFI because the instructions would execute slower. The solution was to edit board_sysinit.c and replace the call to Chip_SetupCoreClock(CLKIN_CRYSTAL, MAX_CLOCK_FREQ, true) with this modified function:

static void My_Chip_SetupCoreClock() {
Chip_Clock_SetBaseClock(CLK_BASE_MX, CLKIN_IRC, true, false);
Chip_Clock_EnableCrystal();

{
volatile uint32_t delay = 3000;
while(delay--) {}
}

uint32_t nsel = 0;
uint32_t fin = OscRateIn/(nsel+1);
// determine required postscaler
uint32_t psel=0;
// determine M
uint32_t msel=MAX_CLOCK_FREQ/fin-1;

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

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

Chip_Clock_SetBaseClock(CLK_BASE_MX, CLKIN_MAINPLL, true, false);

/* Wait for 50uSec */
{
volatile uint32_t delay = 250;
while(delay--) {}
}

// use direct output (no postscaler)
PLL1Reg |= (1<<7);
LPC_CGU->PLL1_CTRL = PLL1Reg;
}