Difference between LPC4357 and LPC4333

[bbarna1]

I have two prototype board one fitted with LPC4357 and second with LPC4333.

My problem is that on the LPC4333, I can not access some registers for example the LPC_CGU->IDIV_CTRL[Divider];

Which is mapped at address 0x40050048. Works on the LPC4357.

What could be wrong?

[jeremyzhou]

Hi Bill Barna,

Thank you for your interest in NXP Semiconductor products and 

the opportunity to serve you.

The LPC4333 also has the set of IDIV register whose address start at 0x40050048 as the LPC4337 does.

So I was wondering if you can upload a complile-able code which can replicate the issue and a screenshot that illustrates the exception error.

I'm looking forward to your reply.

Have a great day,

TIC

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[bbarna1]

Hi Jeremy.

Please use this attached project, and not the previous one.

Many thanks.

Bill Barna

[jeremyzhou]

Hi Bill

Thanks for your reply.

It seems so weird, the issue doesn't occur when doing testing with the OM13070 board which contains the LPC4337 on my site, and the LPC4337 is as same as the LPC4333 exception for the Flash size.

So I'd like to confirm some something with you, then I can report to AE team for checking.

1) Can you replicate the issue on all boards which integrate the LPC4333?

2) Do you find other registers which terminate the reading or writing operation just like the sets of IDID_CTRL registers?

Have a great day,

TIC

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[bbarna1]

Hi Jeremy.

I have 7 boards which fail and 2 that work OK.

All 9 chips have the same numbers

LPC4333JBD144

PFVR32.00 04

ESD18020A

I have only seen this problem on this register.

A call to Chip_Clock_GetPLLStatus(CGU_AUDIO_PLL) will always return zero.

Many thanks.

Bill Barna

[bernhardfink]

When we take the fact for granted, that there is no problem with the LPC4357 in 144-LQFP package, then we need to look at the difference to the LPC4333.

The difference between the LPC4357 and the LPC4333 is the LCD interface and the flash size.

• Can't think of the flash being the reason for this problem
• LCD there or not might be a problem, when the software tries to communicate with the IP block whenit's disabled. maybe it needs to be checked if the software tries to configure something there, switches a dedicated clock on etc.

I'm wondering if the problem also appears when no software is running. Could you make a test with a software which simply runs into an endless loop right in the reset handler. then you go onto the chip and check the access to specific registers with the debugger. By default all blocks are enabled, so every IP block should be accessible.

"I have 7 boards which fail and 2 that work OK."  --> does this mean you have 2 LPC4333 boards which work fine?

Regards,

Bernhard.

[bbarna1]

Hi Bernhard.

Thank you for looking at this problem.

Yes I have two boards that work OK and 7 not working.

I tried the endless loop in reset handler, the debugger can see the

registers at address 0x40050048.

But can not if running as normal with a breakpoint.

LCD not fitted.

All pin mux are default when chip powers up, I only change a few pins for

GPIO and UART1.

Many thanks.

Bill Barna

On Wed, Mar 14, 2018 at 1:19 PM, bernhardfink <admin@community.nxp.com>

[bernhardfink]

So let's assume it is a software problem, respectively a hardware problem caused by software.

• You could move the endless loop step by step to a later stage and silently connect with a debugger to check if everything is (still) ok
• An equivalent way to do this is a breakpoint instead of the endless loop
• LCD fitted or not is a don't care, important is that the internal LCD interface block in the LPC4333 is fused out at factory, so if the software tries to access a register in this block or enables the clock for it could generate an exception.

Now let's come to the key point:  You have two LPC4333 boards not showing the problem. This means that it is not a black & white issue. You're somewhere at the edge of performance with your PCB, most of the devices fail, some very good pass. Don't ask me (yet) why the LPC4357 seems to perform better.

• Could you try to work with a lower system frequency
• Please set more waitstates for the internal flash for test purposes

A topic which is related to the LQFP144 package:  the number of power pins and ground pins is quite limited, if you have a "bad" power supply structure on the PCB it could happen that inductive effects occur during immediate power needs and therfore the internal regulators run into a hickup.

Here also I'm asking myself what happens when a clock for a disabled block is enabled, maybe in combination with pins enabled for this disabled device. I didn't look into your project, so I don't know whether the software adapts dynamically to an existing or non-existing LCD i/f with its configuration functions.

Regards,

Bernhard.

[bbarna1]

Hi Bernard.

You asked if this is happening with other registers and it is.

At line 440 in clock_18xx_43xx.c

uint32_t reg = LPC_CGU->BASE_CLK[BaseClock];

A read from this register hangs the processor. It is the same base address

for the LPC_CGU.

Also the boards that do work, are only partially working. I have found that

UART1 will not properly initialize.

I'm no closer to finding why the LPC4357 works and LPC4333 is not working.

Many thanks.

Bill Barna

On Wed, Mar 14, 2018 at 3:06 PM, bernhardfink <admin@community.nxp.com>

[jeremyzhou]

Hi Bill Barna,

Thanks for your reply.

Maybe you can send a board, as I'd like to test and replicate this issue, then I'll confirm it with AE team later.

You can get my shipping information in the response to case: 00154264.

Have a great day,

TIC

-----------------------------------------------------------------------------------------------------------------------

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

-----------------------------------------------------------------------------------------------------------------------

[bbarna1]

One of our development boards is on it's way to you.

Many thanks.

Bill Barna

[bernhardfink]

Just a quick idea:

I looked through the LPC4333 project and saw that in cr_startup_lpc43xx.c the non-existing LCD block gets a reset instruction:

// Write to LPC_RGU->RESET_CTRL0
*(RESET_CONTROL + 0) = 0x10DF1000;
// GPIO_RST|AES_RST|ETHERNET_RST|SDIO_RST|DMA_RST|
// USB1_RST|USB0_RST|LCD_RST|M0_SUB_RST

Can you please take the bit for the LCD out and test again.

When you write "hangs up the processor", what does this mean? Crashed, or does it just go into a regular exception handler?

Regards,

Bernhard.

[bbarna1]

Hi Bernhard.

I tried removing that line of code, it didn't make any noticeable

difference.

When ever I try to access or write, the system will just hang, the debugger

stops running. I can't see what the processor is doing as the debugger also

crashes.

Sorry I can't seem to get any further to finding the problem.

Many thanks.

Bill Barna

On Tue, Mar 20, 2018 at 3:36 PM, bernhardfink <admin@community.nxp.com>

[bernhardfink]

Sounds like a tricky problem ;-)

Hopefully my colleague can detect the root cause on your board.

I'm still puzzled by the fact that your boards with an LPC4357 seem to work fine. An option which I didn't mention so far is, that the debugger is doing something wrong. So a crosscheck with another debugger (Keil or IAR) or a setup without debugger would be useful. You can check in various locations of your code for register values and printf them out on the UART.

If it is a debugger problem, then our MCUXpresso team will look at it.

A few further generic hints, which are relatively easy to realize:

• Insert a GPIO toggle in all exception handlers. Then you can see if it's ending up there, even if the debugger connection crashed.
• Don't run the chip on 204MHz (look into clock_18xx_43xx.h). This would help if you are running into power supply problems.
• When you are in a debugger connection close all type of windows which could demand for information (register views, memory windows etc). Just reduce it to a useful minimum.

Power supply problems with the 144-pin package: 

• I mentioned it earlier already, such problems can cause such type of crashes. A hick up on an internal regulator can cause a complete crash of the core.
• Reducing the system frequency normally improves the problem
• Adding additional capacitors at the VDD pins could help, but mustn't
• Sometimes there is a temperature dependency, the warmer it is, the better. Sounds strange, but it is this way. The reason is that all signal edges become less steep, causing a reduction of overshoots and therefore release the regulator a little bit. At colder temperature it's getting worse. Tests here only make sense if you found a system frequency where the problem does no longer appear. If you then cool down and the problem re-appears, then it's most likely this type of issue
• Ways to fix it: improve power supply structure on the PCB or use a different chip package with more power pins

Regards,

Bernhard.

[bbarna1]

Hi Jeremy.

Thank you for getting back to me about this.

I have attached a MCUXpresso 10.1.1_606 project.

Also I have a breakpoint at line 336 in clock_18xx_43xx.c.

336 uint32_t reg = LPC_CGU->IDIV_CTRL[Divider];

The variable Divider = 0 and *LPC_CGU->IDIV_CTRL points to *0x40050048.

The same code and library works without problem on the LPC4357.

I can't show you the exception error because the debugger stops working

after this line of code is executed.

Hope this will show you the problem

Many thanks.

Bill Barna