Do you have a “sanity test program” for a microcontroller you just bought? - Page 1
Forum section: electronics / general

author: technix
author_rank: Super Contributor
timestamp: June 21, 2017, 10:24:13 am
content: So far for me I have the habit of loading and running a sanity test program before start working on a microcontroller. Do you have such a program?My sanity test program may seemed simple but it is non trivial: the Arduino “Blink” sketch verbatim, without timing loops, at maximum clock speed. Blinking a LED is trivial, but all the additional hoops and loops pushs this sanity test into the non trivial territory: it exercises the interrupts, timer and GPIO, the three most fundamental peripherals of any microcontroller. Being able to load the program also exercises the programming and debugging interface. Pushing it at the maximum clock speed exercises the PLL if it have one, and puts some pressure on the core itself.

author: legacy
author_rank: Super Contributor
timestamp: June 21, 2017, 10:41:31 am
content: In avionics we have a continuous built-in set of test (also known as CBIT). Is requested by low level requirements as well as by high level requirements, and it's a must for every product.So, when I have to start a new project from scrath, I usually receive the prototype, usually developped around a strange PowerPC board, and I have to be sure everything at least works as expected.So I usually attache the debug cable to force code-inection into the main core, and I usually recycle a part of the said-CBIT code.It's written in assembly, but also in C, with a progressive complexity, from the test of every CPU parts, to cache inihibit, to TLB, FPU, interrupts, mail boxes, etc.If it's all passed, you know that at least you know the CPU and it's local cache and ram on the local bus in the processor-board is ok. Other problems might be located in the mezzanine or elsewhere (who knows where?) along the avionic-bus.Being sure everything is ok takes weeks, and involves a team of testers, composed by hardware guys and software guys.

author: Bassman59
author_rank: Super Contributor
timestamp: June 21, 2017, 04:11:58 pm
content: Quote from: technix on June 21, 2017, 10:24:13 amBy "microcontroller," do you mean "chips that just came in from Mouser" or "Arduino or other board?"For the former, I stuff the board into which the part was designed and run the code for that board. I don't have a use for Arduinos or the like so I don't buy them.

author: JPortici
author_rank: Super Contributor
timestamp: June 21, 2017, 04:31:07 pm
content: with every new project i basically do what you do:connect with the debugger, so run a simple while(1) { i++;} to see if clock is running,then toggle a pin at max speed (bunch of assembly lines) to verify actual clock speed (or better yet, use refclkout)then timer interrupt that toggles a led every X msthen go on programming@legacy: do you have any referral / guidelines on how to implement CBIT? Apart from "getting a job in avionics"?for example, microchip, and i suppose other vendors too, provides a class b library that contains hardware test routines. use them as starting point? once in a while hold everything and do self test? do only at startup?

author: nctnico
author_rank: Super Contributor
timestamp: June 21, 2017, 05:50:32 pm
content: I have more or less a base consisting of a command line interpreter and timer. This also blinks a led. It is not a test for the microcontroller but more to confirm programming works and the clocks are setup properly.

author: legacy
author_rank: Super Contributor
timestamp: June 21, 2017, 09:02:15 pm
content: Quote from: JPortici on June 21, 2017, 04:31:07 pmWe have two experts in PowerPC (hardware and assembly) in our team, they usually assist us. Their code comes from datasheets and their personal experience, indeed they develop everything from scratch. The final CBIT code is designed to be performed during the cold-startup, and also continuously repeated in loop.What I usually recycle from their CBIT-code is just a part of the cold-startup code, plus the glue-code provided by Green Hills, which is useful to force the CPU into "code injection". In this mode the CPU doesn't fetch opcodes from the ram/rom, it fetches directly from the debugger's internal ram. You need a few scripts to do that. Luckily Green Hills comes with a lot of examples and documentation. Well, it's 50K euro toolchain, I would be surprised if they were not provided. Btw, it's all useful stuff since you don't care about anything else along with both compiler and debugger. So I usually just recycle and adapt a few of their script for our purpose and we are ready for the next-step.Nice guys even on the phone, when you need someone answering a specific question.

author: Rick Law
author_rank: Super Contributor
timestamp: June 26, 2017, 10:54:36 pm
content: Quote from: technix on June 21, 2017, 10:24:13 amJust because Arduino-blink runs doesn't mean your MCU is truly well. If you for some reason suspect the MCU not being well, you need to test other things too.I had an ATMEGA328 with both ADC0 and ADC1 blown. I knew how that happened (fed 30Volt to ADC0 and ADC1) so I was pretty sure the impact was probably localized, but I can't be sure the rest of the chip really works. Blink works just fine, even ADC2 and ADC3 appears to run just fine. I2C (ADC4,5) works with the 20x4 LCD just fine. I did not test D2 to D13. But, just because I think it is localized doesn't mean the rest of the chip really work. To prevent other future mystery failures, I replaced the MCU.So, blink working != MCU works.I am a hobbyist, but now I have a little more experience with the MCU (compare to when I blew that other one). So, if another MCU for some reason suspected, at the minimum, for me, I would test all ADCs, D0 to D13, ADC4/5 but this time doing I2C stuff, RX/TX (D0, D1 again doing UART type stuff), ISP pins (doing ISP) , SPI pins doing SPI stuff. After that, I think the MCU is fairly solid.Some with more experience would likely point out other things I have missed.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: June 26, 2017, 11:01:33 pm
content: I set up a timer and interrupt based delay routine, and then blink an LED on an infinite loop with the delay set to ~1 sec. This tests the compiler, programmer, clock speed (if it's not blinking at 1s then the clock is wrong), interrupts, etc.

author: Rick Law
author_rank: Super Contributor
timestamp: June 27, 2017, 12:14:20 am
content: Quote from: suicidaleggroll on June 26, 2017, 11:01:33 pm(1) Wouldn't doing real RX/TX take care of clock accuracy issue?(2) Would it be easier to check the clock by simply put out a PWM square wave to a scope?

author: Mechatrommer
author_rank: Super Contributor
timestamp: June 27, 2017, 08:16:54 am
content: in the end, your sanity check is what features you are going to use... in real circuit, interrupt? adc? comparator? eeprom? sram? flash? whatever. unless somebody is going to pay you good money, then a flull blown hardware test is worth it. my sanity check program is the program, if it works in circuit, then it works.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: June 27, 2017, 04:43:56 pm
content: Quote from: Rick Law on June 27, 2017, 12:14:20 amSure, but I'm not seeing how incorporating another device into the mix, possibly with level shifters, soldering, serial terminal, logic analyzer, etc. does anything more than complicate matters. Eventually you're going to want to make sure your serial speeds to peripherals are set correctly, but this thread is about initial sanity checks.Quote from: Rick Law on June 27, 2017, 12:14:20 amHow is that easier than watching an LED blink? If you want to get a precise measure of clock speed then sure, but this thread is about sanity testing a brand new MCU setup. 1% accuracy on clock speed is a non-issue for this question, what you care about is if you're running on a 4 MHz, 8 MHz, 16 MHz, etc clock to make sure your dividers and clock sources are set right, which is easy to see by blinking an LED on a ~1s cadence without requiring any additional equipment, jumper wires, or probes.Maybe I have a different definition of "sanity test on a new microcontroller" than some other people here. In my interpretation that means a few simple things:1) Can I compile code for it2) Can I load that code onto it3) Is the CPU executing the code I loaded onto it at the expected speedThat's it. Low level testing of other peripherals like serial interfaces, ADC, etc. comes later.If we're talking about soldering an MCU onto an already designed and tested setup with final firmware, then I just load on the final firmware and make sure the device works. I didn't get the impression that's what the OP meant with this thread though.

author: hans
author_rank: Super Contributor
timestamp: June 27, 2017, 04:56:23 pm
content: If it's about sanity checking, then having a programmer program the chip and see a blinking LED is enough.Or even better; a debugger opening a debug session, and the MCU runs code.For these initial tests I skip the PLL. I prefer to use the internal oscillator. Any more development goes towards board bringup for the specific design, which can potentially take weeks to write a complete and working BSP layer for.Any other software that can do with BSP abstractions should be developed on a PC.

author: Rick Law
author_rank: Super Contributor
timestamp: June 27, 2017, 11:14:03 pm
content: Quote from: suicidaleggroll on June 27, 2017, 04:43:56 pmYeah, you and I view that different. I think of it as "everything seem to work". At a later day after I forgot "this component should be suspected", I would have a much harder time trying to isolate the problem.But, I do see your point. Carrying sanity test too far kind of defeats the label "sanity test."

author: Yansi
author_rank: Super Contributor
timestamp: June 28, 2017, 04:15:10 pm
content: I do not see any sense in making such test. As said above, you just test whatever you need to run in your app. (+ you run the runtime tests like the CBIT or Class B or similar, if the final application requires).You are not going to test the MCU as a whole. Not gonna cut it. This is a job for the manufacturer that knows how to do it, so bad MCUs does not leave a fab house. It is a very rare occasion, when a bad MCU gets to a customer. You are very more likely to experience a design bug, but not a production fault.