Dear NXP,Why the lacking documentation?

[lpcware]

Content originally posted in LPCWare by blueo on Thu Feb 12 12:23:10 MST 2015
Dear NXP,

I love NXP mcu's but we design Engineered products ,not writing "romance novels" about them;so we need proper documentation.
To find out stuff fast,not by doing lengthy "experimentations" for every little detail.

You can look up to Microchip,ST and even Atmel...Specifically Microchip; how about sending some of your doc. staff over to Microchip for internship? ;-)

With Love
.
.
.
and some frustration

[lpcware]

Content originally posted in LPCWare by schisanoa on Tue Apr 07 00:45:46 MST 2015
For example, is this document: http://www.nxp.com/documents/application_note/AN10778.pdf also valid for the LPC4088FET208 parts? Reading the keywords on the header of the Application Note I think yes, and why if I search in LPC4088FET208 documentation on NXP site(http://www.nxp.com/products/microcontrollers/product_series/lpc4000/LPC4088FET208.html#documentation) I can't find it?

It's hard to work with NXP product if all the documentation is missing or it is not at the right place...

[lpcware]

Content originally posted in LPCWare by mch0 on Thu Feb 19 12:58:02 MST 2015
Hi emh203,

although I have made quite good experience with NXP support on specific topics I do agree with blueo about the documentation in some respects.
I'll give you an example and you will see that this is not something that can be solved by "what does this bit do in that register" and it can also not be solved in a satisfying way by experiments.
Ok, now my example (GPDMA, just like blueo mentioned).

In my application I have two rather high-speed transactions going on simultaneously. Both are using scatter/gather, i.e. the GPDMA is programmed to reload the descriptors (both channels used here).
When I say "high-speed" that is up to 40 MWords/s.
Now what I need to know is:
- when does the GPDMA start to reload the descriptors?
- how long does this take?
- what is the latency with arbitration if both DMA masters try to access the same bus (you can be assured I try to separate busses as far as I can, given the documentation  - a single figure about the bus matrix!)
- how do the masters use the FIFO associated with each channel (burst? trigger level?)

I could go on here, but you can already see that I need this kind of information before I can really use bits in registers in a meaningful way.
Example: should I try to assign the descriptor reload to "the other" master, i.e. not the one I use to process the request?
I may see a bit for that, but I cannot decide how to set it for best performance without the kind of operational information that is missing. I could be better off trying to assign the masters in a different way, but I cannot decide that with any confidence.

And at this point experiments do not give a conclusive answer. They may indicate a ballpark number, but as an engineer with a product in the field I must cover the worst case in my application.

I don't make that up, I have seen the GPDMA "loosing" a lot more cycles than I would have reasonable expected.
I would like to know if this is a design problem (NXP/chip side) or a configuration problem (my side) that I can solve.

Greetings,

Mike

[lpcware]

Content originally posted in LPCWare by emh203 on Thu Feb 19 07:43:29 MST 2015
1 - I Don't think anyone took it that way.

2.   I know sometimes not getting a response is frustrating but it is always good to fully explain a problem question.   I have found that explicitly stating a problem in written form allowed my brain to think about the problem differently.

I understand the point about performance of a peripheral.   That is many times something you have to do you own experiments regardless of vendor.    From my experience I don't blieve any performance metrics shown by any vendor as they have been fully "amplified" by marketing.        That and performance is highly dependent on your application and use case.      For example,  I needed to get data on the performance of USB transfers via MSC to the SDIO interface.   This is something that practical to know by is dependent on a couple peripherals.   Sometime you just have to spend a day or do running the experiment.   The best thing you can do for the community is publish your results.   If everyone did that,   we would have a great data base!

BTW:    You can achieve a 4MB/Sec through USB0 to a sandisk 4GB SD CARD if you use a 16KB write cache.

3.)   No affiliation.   I just try to be as detailed as possible when I do have something to say

[lpcware]

Content originally posted in LPCWare by blueo on Wed Feb 18 22:54:09 MST 2015
1-First of all I didn't mean to be rude.if my original post has been inconvenient to anyone I apologize to them.just sarcasm!
2-emh203: I could be very specific but I don't think it would be useful on this forum.If I mentioned some stuff,would they respond? I've asked some stuff before(On this forum and via Tech support) but didn't get any proper response.Besides the doc's are generally flawed. for example if you need to estimate the performance of DMA(and bus arbitration ...) you could find needed info for other vendors and some of them even have App notes to help and accelerate your job,but NXP doc's lack such features and details and you'd need to run "experiments". Obviously,time is very critical.
For another example you could look into many complaints (like the one above by schisanoa ) about EMC.
NXP has some App. notes but there is much room for improvement.
3-emh203, If you are affiliated with NXP, I'd be grateful if you relayed this and helped us.
4-Again NXP MCU's are great,I just wish so was their support! I recently had a question for Freescale.There was an online chat which immediately responded.

have a nice time

[lpcware]

Content originally posted in LPCWare by emh203 on Mon Feb 16 12:21:15 MST 2015
I think you need to be a lot more specific to get any useful results.   I have used chips from all the major vendors.    The NXP documentation is on par with the other vendors.   All documentation has mistakes, oversights, etc.    I find the NXP documentation fairly straight forward.  Look in the datasheet for individual part information,  and in the reference manual for the peripherals.     The only spot where I thought there could have been improvement was the SGPIO as it is a complex peripheral with many use cases.


I would spend some time detailing what you mean "make it better".   That is a nebulous request and impossible to do anything with.    Everyone's brain works differently and would organize information differently.    Since no one else on the forum can read minds,  you may want to consider formulating the request with a little more detail.  :-)

For example:

"On Page 252 of UM12345 Rev A, there is a description of the WARP_DRIVE peripheral.   Table 3 shows the "POWER_RELAY" register descriptions.   Could you please clarify the behavior of the bit "ENABLE_DEFLECTOR_CONTROL"?  I don't see where it's behavior is described".


That is a lot more helpful than "hire microchip interns".

[lpcware]

Content originally posted in LPCWare by schisanoa on Mon Feb 16 02:52:43 MST 2015
I agree with blueo, often in order to find out some document related to a CPU, I need to find in to other CPU documents in NXP's web site. Specially with the LPC40XX mcu, but not only. One example may be the SDRAM interfacing documentation, that I find in LPC43XX documentation, but NXP staff told me that due to the same EMC controller inside the MCU the documentation is the same also for the LPC4088 parts...

It's hard to find out the right documentation, and adding to this, the costumer support is not enough fast to get answer about this kind of problem but not only.

Take this post as a feedback for future improvement.

I have also another question:

is there a way, to get a fast access to the customer support? also by pay, sometimes is cheaper to pay a fast support ticket, than wait for 3 or 4 week to have an answer

thanks for your attention

[lpcware]

Content originally posted in LPCWare by nerd herd on Sat Feb 14 10:31:02 MST 2015
Hi blueo,

I'm sorry for the frustration our documentation has caused. Feel free to leave feedback for us on what specific thing we can do better on. :)