LPC4370 - how hard is the learning curve? How risky is it?

[lpcware]

Content originally posted in LPCWare by splin on Mon Sep 08 16:58:25 MST 2014
I got quite excited when I came across the LPC4370 with its very attractive features - especially the 80MSPS ADC and the multiple cores. I bought a couple of LPC-Link2 boards to play with, but I'm starting to wonder if I'm doing the right thing having seen in these forums the number of problems people are having getting things working, sometimes without success. I realise that many of these problems are probably common to all the ARM Cortex families and not specifically to NXP's.

What concerns me is the sheer complexity of these devices; with an enormous user guide (1420 pages!!!) its likely to need a great deal of effort to learn how to use it and understand the quirks in the device/documentation and the tools. Worse still it seems likely that there will be a number of bugs in the silicon and documentation which haven't been found yet (or at least admitted to by NXP in errata sheets). I'm not suggesting that NXP are in any way worse than any other manufacturers, but having run across bugs in devices in the past I am aware that if you run into one you can't fix, you might have to abandon the project having done a lot of work. Its hardly unknown for devices to be introduced with a fanfare of publicity, where it turns out that one or more of the flagship features never works properly or only gets fixed in a later product.

The number and severity of bugs depends on how widely the device is used, how complex the device is and how incremental its development has been - adding small features at a time tend to be less prone to problems given that there are plenty of opportunities to fix the bugs in those features added previously. It also depends on how far away from the norm you are in in the way you use the device. The problem here is that as a newcomer to the device family, and with the huge number of different ways to configure and use the device, it's hard to know if you are trying to use the device in a way that its designer didn't expect and thus test thoroughly, and worse no-one else is doing it that way so they can't help.

I realise that all the core IP is from ARM and thoroughly tested in a wide variety of products, but there is a lot of complexity in the circuits unique to the LPC4370, such as the Serial GPIO and the multi-core design. I have played with an STM32F4 discovery board and eventually managed to get their triple interleaved ADC example working - after discovering Emblocks which provided reliable debugging but I'm new to the NXP products. I know there's a lot of ARM Cortex learning to do but there's a wealth of information and help out there on that front.

So the question is, am I worrying unnecessarily and exaggerating the risks? Once I've got to grips with setting up the basic initialization, configurations and clock options etc. is it your experience that its straightforward to just concentrate on a peripheral/feature at a time without worrying about unintended impacts on unrelated areas (or at least you assumed to be unrelated!)?

Is the LPC4370 relatively mature with many of the problems, if there were any, being addressed in its predecessors (the LPC4300?)

When you run into difficult problems is their plenty of help? As a one man band I know I don't have any clout with the manufacturers and can't expect to get any detailed assistance, especially if my problems are considered to be unique to me.

Is the example code provided reliable and have developers found it detailed enough to demonstrate the usage of hardware features in realistic, rather than superficial ways?

Have you tried using a feature but given up because it was too complex or the documentation was incomplete/incorrect or misleading?

Has anyone had much experience with using more than one core and not found the debugging issues too intractable?

Thanks for reading this far (if you did!) - I'd welcome your thoughts on the matter.

Regards,
    Tony H

[lpcware]

Content originally posted in LPCWare by peterrq on Mon Sep 22 01:26:22 MST 2014
Having a common ARM core & (I guess) some core ARM peripherals certainly helps reduce risk.
I will have to try the recommended IDEs as I am missing a 'refactor' button in my Keil IDE....

Thanks.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Sep 19 03:56:57 MST 2014
Sorry, we are unable escalate. You will get a response.

[lpcware]

Content originally posted in LPCWare by mch0 on Fri Sep 19 03:27:38 MST 2014
I'n not from NXP, so no MAC support from me.
Just in case you'll get over the 256k limit of LPCExpresso: there's another IDE called "CooCox".
As far as I remember it has no restrictions at all.A colleague uses it for 2 years now, he's quite happy with it (target is LPC1769).
I tend to stick with the "mainstream" IDE, though.
Up to now I have no gripes with LPCExpresso whatsoever.

As far as support goes right now I have made good experience, quite recently, too.
What I really miss is really good documentation and sadly enough this is a general problem not restricted to NXP.

As an example the LPC43xx has an UM with 1400 pages and yet sometimes (in my opinion) vital information is missing.
Example: What is the penalty introduced by the AHB bridges to the peripherals? Can the two GPDMA masters run in parallel when one accesses SRAM region x and the other one SRAM region y when x and y are mentioned to be connected differently to the bus matrix.
If you want to get the max out of the chip you will want to know that - I have already hit the ceiling when running two fast GPDMA transfers in parallel earlier than expected.
The same gripe for the LPCOpen drivers and libs. They are good, but I find myself skimming through the code to find out which function to use which way.

Alas, the same problem exists with other manufacturers as well.
At the end of the day for me it's the performance I can get out of the chip (of course that depends on the application).
In my opinion a strong point for NXP is that the concentrate on a single widespread core (ARM).
That probably leaves them more design ressources for their peripherals.

Mike

[lpcware]

Content originally posted in LPCWare by peterrq on Fri Sep 19 02:58:06 MST 2014
Thanks, thats useful to know that there is a free IDE.
I have already contacted NXP and am waiting for a reply. Can you help escalate? See my post. The MAC does latch & I cannot recover it.
It is the delay that worries me, that coupled with the relatively low volume of traffic on this forum. Suggests fewer users which sometimes leads to a bumpy ride.
Be happy to be proved wrong with a reply from NXP today!

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Fri Sep 19 01:50:00 MST 2014
The LPCXpresso IDE is free (up to 256k code size). Unlimited code size (in the Pro Edition) is $495 and includes 1 year of email support on use of the tools. Of course, there are many other free and paid-for tools for our parts (Keil, IAR, Rowley, Yagarto etc) - the choice is yours.

If you want help on the parts themselves, use the Get Support / Ask NXP Experts section on the main NXP website (www.nxp.com). If you are purchasing from a distributor, many of them have FAEs that can also provide you with help.

[lpcware]

Content originally posted in LPCWare by peterrq on Fri Sep 19 01:40:03 MST 2014
I have found it easy enough to get started. Started 2 weeks ago & have TCP/IP stack running with UDP, IGMP and HTTP.
Hit my first major chip issue though & I would say that support is limited.

I have come from the PIC32 world & the forums there are much more active. I can also raise a support ticket & I will get a prompt response especially if I have paid for development tool support. I have phone numbers I can ring. Not so with NXP. If I am wrong then please let me know!

PIC tools also tend to be free. I have developed many industrial applications using just the free tool set. Only once did I needed to buy a compiler to make a bootloader & that was only because I was too lazy to rework a linker script. TCP/IP stack comes free. IDE & debugger are also free though MPLAB-X IDE struggles with C++ debugging.
CMSIS cpu/board neutrality has the edge on PIC 'Harmony' IMHO but then if you use an OS then cpu/board neutrality is not so much of an issue.
Obviously you have more choice of parts with ARMs.
I would not recommend one CPU over another, its swings & roundabouts. Support (or lack of) has me worried at the moment. I can deal with a naff IDE (MPLAB-X) but getting a chip function working needs support.

[lpcware]

Content originally posted in LPCWare by JohnR on Tue Sep 09 10:25:07 MST 2014
Hi,

Thanks for the fast reply.

In our application we need good DAC resolution, so we could not use the on-board 10-bit DAC on the FET256 anyway. At the moment we generate the SPI DAC waveforms using SGPIO, which saves a real SPI channel.

JohnR.

[lpcware]

Content originally posted in LPCWare by mch0 on Tue Sep 09 06:56:14 MST 2014
Hi,

at this point I use the FET256.

The reason is not the ETH but the missing DAC output on the FET100.
Additionally at one point we wanted to test the performance of the SDRAM interface.
However, as the project progresses, we may go back to the FET100 and add the DAC feature externally. The SDRAM interface had low priority anyway.

For the PHY I use the KSZ8081RND which was the cheapest of the bunch I looked at.
I also generate the 50MHz internally, i.e. the 4370 does it from the 12MHz. Saves the second crystal for the PHY. Works quite nicely so far, but I have not done extensive testing on the network side.
That is, the cable to the host is short and interference is low on the bench. So I cannot say whether another PHY would make a difference (errors on the network side) or whether a second crystal woul improve something in the field. I doubt both.

Mike

[lpcware]

Content originally posted in LPCWare by JohnR on Tue Sep 09 06:01:21 MST 2014
Hi,

You write that you are using the Ethernet module on the LPC430.

Which version of the chip did you use -  the FET100 or FET256?

I am currently using the LPC_Link2 card as a prototype front end to a data acquisition system but would like to add Ethernet connectivity at some stage on a custom designed board.

JohnR.

[lpcware]

Content originally posted in LPCWare by mch0 on Tue Sep 09 02:43:18 MST 2014
Hi Tony,

I also got excited about the 4370 half a year ago for exactly the same reasons (HS ADC, speed+cores) and in addition we will use both Ethernet and both(!) USB ports.

I also started out with the LPClink2 for a quick start, but now we have our first own board up and running.

I agree that the device IS complex, but that's the reason one gets excited in the first place.
For me the LPCOpen approach is well suited, that is the, the supplied peripheral drivers as small modules.
There are other approaches, like the one Infineon has with DAVE.
I didn't like that so much, but this is probably because I'm too old a dog to learn new tricks easily.

Yes, there are bugs. Until now I have not hit (knowingly) an undocumented silicon bug, but several ones in the LPCOpen drivers.
However, this is because I do lot of "non-standard" things which take the libraries to corner cases :/
I am sure that for most use cases the libraries do fine.

In one recent case I got quite outstanding support from an NXP engineer (in that case, not a bug but a problem with the toolchain).

Right now I do not regret our decision to move to this uC.
I've got both USB and Ethernet up and running, i.e. communicating with the host, within 2 weeks. This is faster than I expected, especially if you consider that I used an "unsupported" PHY for which I had to adapt/write a driver and also an "unsupported" external SPIFI flash.

Regards,

Mike