Confirming that a "new" API function or unique parameter operates as you (hope)/expect...

Hello cb1,

Do you suggest a test board and test code for sanity?

Regards
Amit

Hello Amit,

Indeed - via a "one-time" - proper design & build - of the compact test board.   The board is (always) then available, known, and quickly/easily (and only) correctly insertable.   (via polarized header/connectors)

Even w/different ARM MCUs - from different vendors - our forethought enables that same test board/connection to simply, "Plug in!"   That "reusability" ensures correct - almost "unthinking" set-up & operation.

Again - even for different ARM MCUs - from different vendors - the SW is very much the same - accommodating only the necessary changes demanded by the target MCU.   (this is just one of the methods we were past taught while, "Going Public!"

Hello cb1,

Does it make an assumption on the header layout on the main board with the MCU?

Regards
Amit

Hello Amit,

Yes - we (early on) attempted to accommodate each/every vendor's (different) header arrangement & pinout.   (can you say, "Krazy Making?")   Thus we developed a more logical, Port/Peripheral Group header layout - and it is to that (constant - always the same - from MCU to MCU/Vendor to Vendor) standard our, "Common, Reusable Test Cable "plugs in."

Unstated earlier - but as you now asked - we can attach multiple (identical) such test boards to each every "test/functional exit" header on our MCU boards - accomplishing an extensive board test - as/if needed.

Now in the event we'd design & deliver a high volume MCU board (> 10K EAU in our case) we'd likely move to a larger and more unified, single header.   (and them employ a larger scale test board)   For even larger volumes we'd employ "bed of nails" test set - avoiding header/connectors entirely...

There is another "method" to this "madness."   Our clients find the "consistency" of (always the same) header pinouts and "all Peripheral Signals + Power" resident upon a single, minimal header - a great advantage.   Our decision to "naturally group" related peripheral signals - spectacularly eases, speeds & enhances "real world" connections & board/peripheral test/verify.    MCU vendors - instead laying their eval boards for the (apparent) convenience of the board designer - force gross signal separations and most always require multiple, overly-wide ribbon cables - to "harvest" a simple, peripheral port.

Depending upon the frequency and variation of board usage - that (slight) initial cost saving (resulting from "convenient" board layout) may be fully absorbed and (likely) far exceeded by the (ongoing) extra time & effort such non-peripheral-grouped, board layouts demand...

Hello cb1

Indeed a sample program/example and a board can be done for the launchpad on both booster pack header and the extended breadboard header. But I believe doing this on a custom board may not be easy as every customer designs a board for their application before "lightning" strikes.

Regards
Amit

Hello Amit,

While what you note is true - it's bit outside the thrust of my post, "Confirming that a "new" API function (or parameter) behaves as expected/hoped!"

I argued (against) a, "Code & Pray" methodology - as too often practiced (and reported) here.   Indeed the post which triggered this thread sprung from a (recent) poster's failure to describe his "test" of a failed API function.   Without a quick, easy, known good - and STYLIZED - test methodology - each/every such "test" proves an adventure - does it not?   (while wasting counless time, effort, and "inviting" mistakes...)

Hello cb1,

I have always used the basic API to get a module before wrapping it in more "sensible" API. So my code always start linear before forming a series of interrupt driven calls. Does that sound more like as one possible method to achieve the same?

Regards
Amit

If we return to my opening post (this thread) I was speaking more to the point of "monitoring" expected MCU output - so that at minimum - we have (some) confirmation of the basics.   Hundreds (perhaps thousands) of posts here have reported, "Peripheral N, does not work" and only (rarely) does the poster report the efforts they've made to probe and/or examine the MCU's (expected) output signals.

That was (and remains) the central point - raised this thread.   Now any software technique which speeds, simplifies is welcomed - we tend to try (at least initially) to avoid any/all "complications" which interrupts (usually) introduce.

Over time the value of a, "Stylized Test board and/or basic test SW" becomes more & more evident.   Haywire, always unique hook-up & devices present uncertainty - demand great focus/care - and are completely eliminated via the "Stylized" technique - proposed here...   (constant "wheel re-invention" is not especially efficient!)

Hello cb1,

OK. Then we should start adding context to the thread. I have put one of my techniques: and would elaborate the same as well.

Regards
Amit