Greatest Hits from Tech Support!

(sigh) Clearly folks who don't understand the question(s) being asked/issues being presented -- ditto the referenced SO post : Customer is suggesting we shouldn't use Freescale (NXP?) in future;

Why? Because they are wary of the quality of the support available? Farming your tech support out to users is always a dubious business strategy!

Because the expected support will be better?

Don, sorry if the context wasn't entirely clear. Freescale/NXP provide many dozens of examples. Typically a good place to start when using a new tool chain! I pared down one of their examples show that they've misconfigured memory management and heap size for their examples...

In the context of their examples, typically run under a debugger, traps would be very helpful to sort out configuration issues.

I'm quite astonished at the answer though:

"It's really OK that malloc returns a pointer outside the heap, because in my blinky example it didn't cause a problem..."

It gets worse though. Their examples for FreeRTOS are misconfigured so that:

- they will blow the heap,

- the FreeRTOS-aware debugger crashes,

- newlib isn't set up compatibly with FreeRTOS memory management,

- etc.

See ya, Dave

Yes. I'd expect part of the example to HIGHLIGHT the differences in the execution environment. E.g., "need big heap to support the allocations in this example (other example doesn't need ANY heap, etc.)"

I usually start with crt0.s and the "helper routines". This removes a lot of uncertainty from "what I'm seeing" (no need to wonder what lies UNDER the examples) as well as gives me a general idea as to what the vendor THINKS that I will be doing.

And, as I'll inevitably have to tweek these things for the OS that will be supporting the executables, I can nail down those customizations sooner rather than later (I like to have an OS up and running from day one)

I think you are being generous saying "misconfigured". While I can't see how all these parameters are defined/established (code elided), I can't imagine any way that the result (0x20005c0 IIRC) can rationally come from the start/end/request of your example. Were you able to track down the source of the error?

The invariants give me a (portable) hook to a debugger and/or run-time exception handler. Redefine the macros/ftns and I can "throw" the error in a variety of different ways as well as take a variety of different remedial actions. (kill the application, suspend the offending task, log to a blackbox, etc.)

fsub(subtrahend, minuend) { result = subtrahend * 3 + minuend / pi result = 2 return( result ) }

"Works fine -- cuz subtrahend is always two less than minuend in my examples!"

I found the MISRA "excuse" even more alarming -- I didn't see any indication that it even APPLIED (i.e., as a constraint imposed by a client/employer/industry).

because FreeRTOS makes demands that can't be met (and doesn't verify that they HAVE been met)? Or, because of bugs like the above (that FreeRTOS can't do anything about)?

Sounds like the folks who pieced together the support didn't do a very thorough job.

IME, the folks who write the app notes (hardware/software) and these sorts of "examples" aren't typically a "cherished resource". Perhaps summer interns, fresh hires, etc. Company is focused on selling silicon, not software. Only pays grudging lip service to the software in order to get the hardware sold!

[Nowadays, even worse as so many chip designs are pieced together]

I had a client show me his first pass of a hardware design to give me an idea of where his project/product was headed. It was hard to politely say, "This will NEVER work!" (it wasn't like it could be tweaked A LITTLE to be viable).

After gently pressing for details of portions of the circuitry, ("So, what are you trying to do, here?") he eventually folded and said he'd pieced it together from app notes. (OK, maybe he transcribed things inappropriately or made unfounded assumptions at the boundaries of each sub-design).

When I later examined the "source app notes", the flaws were present there, as well. I.e., no one had apparently ever BUILT the circuit that was published! AND, no one had ever proofread the document with even a rudimentary understanding of the material presented (lest they would have found the errors before making it into print).

I learned that when I document things, I have to cut and paste the ACTUAL source materials into the final/formal document -- to ensure no transcription errors AND that the design/circuit/code is EXACTLY as I'd implemented.

I try to "own" all of the IP in my designs so I *know* how they all work as well as how they are likely to interact. E.g., my standard libraries were crafted before the "reentrant" versions of the functions that have internal state (e.g., strtok()) came to be. So, they magically work when hosted by any of my OS's -- because my OS's are integrated with their implementations (and automagically handle the thread-specific state).

The bottom line is that I can have a real application running on bare metal very quickly -- I just need to get the interface to the target up and running. Fewer unknowns, fewer surprises.

[They're TOOLS. They're supposed to FACILITATE, not HINDER!]

Returning to my final queries: is the reason the client wants to move to Kinetis/FS parts because of the "support quality" on the NXP parts?

tto:

bug:

The community is a forum for users, the fact that sometimes people from Fre esc...ehm NXP answers is not granted. If you want a fast and detailed answer you need to send an email to the sup port.

The community is not very good, answers from NXP (usually from Alice_Yang) are usually not very useful.

2-3 years ago I found a very nasty bug in the Processor Expert [1] I2C driv er: if you shorted to ground the SDA line the driver got stuck in an infini te loop, a reset was needed. Spoke (through community) with a bunch of people, and a certain point also a guy from Freescale (supposely the guy who wrote the driver): for him it w as OK because the short to GND could never happens... Don't know if they solved the issue in the next update. [1]: yes, I know, but I had to put together something very fast, so...

Mmhh not sure, some are in the longevity program (the EA family for automot ive as an example). And in any case the kinetis are far better for motor co ntrol than the LPCs. Also the IDE seems to be in active developement so who knows.

Bye Jack

And you will be sadly disappointed. I would love to see this in all examples, but even partial notes like this are pretty rare.

The problem in this instance (and similar), is that there are many other parts of the puzzle...

There is no excuse for this kind of error. "Misconfigured" because this error is a combination of errors in ALL of:

- linker file

- library configuration (newlib)

- external hooks provided as required to support library

- overrides in project files for things like heap and stack size

- unwitting use of library routines that use free storage

- etc.

Of course, I had to get something working to the customer months ago! I will try to put together a web page explaining the components, and providing working examples for:

- bare

- FreeRTOS

Now you are being extremely charitable ;-)

In this case the support operation appears to be Chinese. Race to the lowest cost, quality be damned...

I'll raise you one: I've seen the all of the above in a shipping product! Best app note blunder I've seen: serializer-deserializer note said the parallel lines had to have equal length traces! Think about that one for a bit. Witless non-engineer designed a board using low-end free CAD trying to do this...

And deliver the PDF component spec sheets with annotations appropriate to the part usage in the design...

newlib also contains thread-aware malloc family for this purpose. In the Freescale/NXP case here, they failed to properly set these up.

A combination of factors: tools and documentation not updated for 2+ years, bugs everywhere, extremely poor examples, miserable support, and worries about the future of Kinetis product line after years of Freescale austerity, NXP merger, and upcoming potential Qualcomm merger. Utter disarray with the tools: Freescale started with their "Processor Expert" component system, discontinued it for a new SDK, released an updated SDK with numerous undocumented incompatibilities, the examples and documentation do not use the current tool set, etc.

The hardware is extremely capable, but challenging to use with the above issues... NXP is threatening to release support based on their Expresso Eclipse (replacing the Kinetis Development System Eclipse), and rationalizing their tool support this spring. We'll see how that goes. I did a couple products using NXP Cortex M0 a few years ago and had good experience with the NXP tools (and support when their were tool issues)...

See ya, Dave

NXP "encourages" posting to the user group first. I've had tech support tickets responded to equally slowly.

One of the worst I've seen...

Alice is truly special. Usually fails to understand the question, and often just says "re-install all the software and maybe it will work".

We're not doing motor-control.

KDS will be replaced with NXP's Expresso shortly...

I wouldn't doubt it. Rather, I'm indicating how examples can be used

*effectively*. Every (virtual or otherwise) "call to tech support" bears a cost -- for the provider AND consumer! And, while consumers ultimately pay all of the costs they "impose" on the provider, the reverse is also true: providers eventually end up paying the costs that they've forced/coerced on their consumers (in terms of product satisfaction, loyalty, etc.)

Its not hard to create good examples -- it just requires the attitude that there is intrinsic VALUE in the examples.

I'm a hardware person, by nature. So, I immediately look at the lowest layers of the software system to see what I can/should "expose" of the hardware and what I should deliberately obscure. (e.g., in some cases, exposing the underlying page size of the MMU is a win; in others, a useless detail).

Undoubtedly "misconfigured". But, the code could have SCREAMED of this instead of letting you "trip over" it.

// success ASSERT( allocation != NULL ) ASSERT( allocation >= heap_start ) ASSERT( allocation+allocated_size-1 > a very thorough job.

Who is there to act as a "check" on them? The fab line, no doubt, has inspectors ensuring the quality of the components they are producing. Where is the equivalent for their documentation/support?

(Ans: user community. And, is anyone/corporate actively watching the community's grumblings as a crude indication of the quality of the support THEY are providing?)

There can also be an impedance mismatch -- folks focused on building silicon may not have the skillsets to understand *using* it!

We were car shopping, recently. The quality of the "tech" in modern vehicles is abominable. You have to wonder how a "professional" could produce such crap -- regardless of the hardware/cost constraints!

Obviously, the car manufacturers don't have that expertise and farm it out to a third (fourth?) party. OK, that's understandable and likely makes good business sense.

*But*, because they don't have the skillsets to understand what is possible, they can't adequately evaluate the quality of the resulting product! And, the chosen vendor (assuming he is NOT being unscrupulous) can rationalize away any behaviors as LOGICAL consequences of the problem addressed.

E.g., I recently "misplaced" the local JCPenney store; couldn't recall on which of several parallel streets it was located. "Ah! Let the car's GPS give me the address -- no need for 'directions' once I know which street its on!" Type in JCPENNY [sic] and select from the menu presented... but, the street names are all wrong! "What the hell did I do wrong??" Long story short (_Clue_: "Too late!"), the locations found were located in OH (I'm in AZ). There's a difference between JCPENNeY and JCPENNY and the search algorithm isn't smart enough to think: "What are the chances that he really is looking for a destination 1500 miles away?"

Had this been demoed to an auto executive, the implementation would look

*perfect* -- it FOUND the "JCPENNY" that the user specified! Would the auto executive have had the initiative to suggest this would likely NOT have been what the user sought? Would he have thought of imposing some sort of distance/travel time criteria on the result to check for sanity? "No results (JCPENNY) found within 100 miles. Expand search: Yes/No?" [Or, better yet, a SOUNDEX implementation?]

I watched an engineer design a ~8x10 multilayer board covered with DIP switches to configure his product (which was another board) -- in a MICROPROCESSOR CONTROLLED DEVICE (didn't it occur to him that the processor could do this stuff *for* him and improve the UX?)

"Impedance mismatch"

I approach that by creating a "circuit description" document. This lets me speak less formally -- but more specifically -- about what I did and why I made specific design choices. Often, The Next Guy may not have the focus to think-ahead to all of the potential issues that he (now "his" product) may encounter. Having a forum where I can speak to him avoids his faulty "optimization" of my design (i.e., removing things whose purpose he doesn't immediately grasp) :>

Of course, the same is true of software: "Here, there be dragons" *should* ratchet-up the reader's attention!

So, you're (they're) unhappy with the *provider*, not the *product*. But, mainly from the support side of the picture (i.e., its not like you're having a hard time getting parts or defects in the parts themselves).

I.e., why buy from Walmart when you can buy from Costco?

Sad as they *could* fix this by throwing some resources at the problem. But, until they see a cost to NOT doing that, it is unlikely that they ever will! :-(

I'm pretty much "stuck" having to roll my own tools as my execution environment isn't typical (distributed multiprocessors, task migration, etc.). So, I lose a lot of "pretty" (that would be available in fleshier toolsets) but gain a lot of "essential" (that would have been absent, for my environment, in those verysame toolsets)!

[Eventually, I'll have to make this stuff "ready for primetime" but that's low on the priority list... only so many hours in a day!]