I'm using NXP microcontrollers since the LPC2106 and always appreciated the excellent user manuals. I managed to convince my former employer to base new hardware designs on LPC controllers rather than the Renesas parts they used at the time I joined the company. Part of the advantages I mentioned was the excellent documentation and full openness of
compiler and hardware. Long time ago (200x years). At the time I had a close look at alternatives (ST microelectronics, Atmel, Analog Devices) but none satisfied me.
Now in the year 2017 I want to get started with LPC546xx and also LPC541xx but find myself looking at alternatives again. Not just for knowing for fun what other manufacturers provide, but as a real alternative. And YES, Analog Device's CM4xx caught my interest...
Why? Why would a loyal user commit 'treason' and take all the additional work to get used to a quite different device?
Because he has a notion of freedom: he uses his own libraries and nothing but his own libraries. And NXP tries to put a 'foot in the door' to HIS code running on the LPCs. By urging him into using a closed source library function to switch the core voltage of the LPC54xxx. That is an absolutely crucial part the seems to interact with the PLL, so it's not some fancy add-on he can opt out, but something that's needed for every serious firmware. An underclocked LPC54xxx is of not much use, but that seems the consequence of purely open firmwar. FOUL by NXP!
I have no problem with ROM-API routines (I use sometimes on LPC800) which I can opt out, whenever I have concerns.
But not documenting the core voltage register interface is something very different.
Maybe, no user has explicitely made a requested, so I do it here:
NXP, please do fully document the PLL and the voltage settings required for running the core at full speed and do not urge me - your customer - to use some library 'xy' to do that. And please do it quickly. I have to do my job in a limited amount of
time and I'm not able to wait.
This issue is related to this question ('assumed answered' haha - NO! It is not answered!)
So I really hope, a responsible person takes action at NXP, quickly.
Or better, prove me wrong and show me, where to find the information, which should have been in the user manual in the first place...
Keep you bullshit API - I don't need it any more.
You can remove me from this forum, because I switched over to Analog Devices.
Thanks for making this step easy for me.
The Power Profile API settings have quite a bit of writing to transfer from C code, so we will publish the source file instead of Users Manual. The source will be publish early Sep 2017.
Eventually we will get to LPC546xx Power Profile API. Do note every chip is different, which include the internal power planning, this mean you cannot take the LPC5410x Power Profile API and apply it onto LPC5411x with just different settings. For newly released products like LPC546xx, our suggestion still remain.... use the Power Profile Library.
We appreciate your loyalty to LPC Microcontrollers and feedback.
As you pointed out, the user experience by having a good User Manual is critical, and we have been tirelessly updating the UM (which have grown from the 280+ pages in LPC2106 to >1000 pages on the LPC546xx) , but it's never 100% done. In addition to UM, the users are demanding driver codes (LPCOpen and SDK) which make setup easier for them.... though this might not be your case. On to your subject, here's my explanation.
The PLL is fully documented in the Syscon chapter, see section : System PLL functional description
You can write your bare metal code without relying on the LPCOpen SetPLL API.
The missing part is the need to call the Power Profile API first to ensure the internal regulators are providing the sufficient voltages/energy for the chip target operating frequency. We will include this statement in the next UM release.
So why don't we expose all the registers used in the Power Profile API?
With advance semiconductor process and the push for lower power (active and leakage) and higher performance, LPC Micros integrate advance voltage frequency scaling to achieve that. LPC Micro team had run extensive bench characterization and tester correlation to ensure these settings (flash wait states/internal regulators voltages, frequency etc) are right. It is very complicated to explain the behavior of each setting and provide a good document to ensure user do not set the registers wrongly. The Power Profile API provided in the LPCOpen driver ensure the user can get the power /performance. I fully understand bare metal code writers do not want to rely of API calls from supplier, but at this moment we have to ask you (and all LPC users) to trust that LPC team.
Hope this clarify things.
thanks for your explanation. I understand that the power profile actions are complicated.
Yet there's no explanation why this source code has to be kept secret and thus cannot be smoothly integrated or simplified in bare-metal source code. That's the point.
The product release schedule is always very tight, sometime we might need to update the Power Profile API lib during the early release phase. We do the update via the SDK & LPCOpen library.
We do plan to share the code of the Power Profile API settings after the product is released for >9months production.
It will be shared via the UM update. Obviously the LPC5410x will be the first to get this, followed by LPC5411x. The technical doc person is working on this now.
This is really good news!
I'd like to use the LPC54xxx and I do appreciate you're planning to release the Power Profile API settings.
Does this plan apply to LPC546xx, too?