Post by thread:[PIC] How to test

Hi, Give one or two devices to students and tell them the firmware is super unbrakable and no way to fail it - and wait couple of hours :-) Tamas On 9/26/07, Mauricio Jancic <.....listasKILLspam@spam@janso.com.ar> wrote: {Quote hidden}> > Hi, > I need to implement some secure, safe testing procedure for my > firmware. So far, I have manually looked at every function, but that might > miss some combination of events that might present a possible failure. > > I would like to know if there is a know method to effectively test > and diagnose the status of features in firmware (programmed in C or > assembly). > > Thanks, > > Mauricio Jancic > Janso Desarrollos > Microchip Design Partner > http://www.janso.com.ar > infoKILLspamjanso.com.ar > (54) 11-4502-2983 > > > -

Mauricio Jancic wrote: > Hi, > I need to implement some secure, safe testing procedure for my > firmware. So far, I have manually looked at every function, but that might > miss some combination of events that might present a possible failure. > > I would like to know if there is a know method to effectively test > and diagnose the status of features in firmware (programmed in C or > assembly). > > Thanks, > > Mauricio Jancic > Janso Desarrollos > Microchip Design Partner > http://www.janso.com.ar > .....infoKILLspam.....janso.com.ar > (54) 11-4502-2983 > > > There are three ways I test firmware during and after development: 1. ICD2 or ICD2 clone: The best way, but NOT available for all devices; only those with test vectors already built-in, only about 20% of the PIC repertoire.. 2. MORSE CODE beeper: This only needs ONE I/O pin. I program the device to send critical values out as MORSE code from the I/O pin. With a slight delay between each 2-character pairs in HEX, you can dump critical values that way. Of course, I am familiar with Morse Code; but it is easy to learn for the 16 HEX characters in any case. This uses about 30 code words and 4 registers internally, and externally, a piezo beeper from Radio Shack. 3. DEBUG / DIAGNOSTIC message: This also only requires ONE pin. The device sends out a dump every two seconds. The output takes the form of an 82-bit message, of which two bits are start bits and the remainder is 10 bytes of dump data. The data is manchester mark code (_---_- )is a '1' and (_-___-) is a '0'. Needs a PC application to read the data. Uses about 40 code words and 14 registers internally. I have been working in my spare time on a way to use ONE pin as a bidirectional debug tool; part of the tool would be a PC application that would issue the controls and pickup the data in the same packet. I am trying to keep the PIC end below 125 code words. It would even work for the PIC10F device in that case. But don't wait for it, I am busy right now.

Hi Bob, and thanks. This is not quite what I meant to ask. In the software industry, for desktop computers or systems that don't have "limited" resources, you can use Test driven design, which, according to WikiPedia means: "Test-Driven Development (TDD) is a software development technique that involves repeatedly first writing a test case and then implementing only the code necessary to pass the test. Test-driven development gives rapid feedback. The technique began to receive publicity in the early 2000s as an aspect of Extreme Programming, but more recently is creating more general interest in its own right" I'm familiar with the tools and things we can to to trace bugs, but I'm looking for a way to make those bugs appear on my projects. For example, a few years ago, we found a very stupid bug on one of our products. There was a call to DelayS( time ); and if time was cero, the delay will count 256 seconds. These are the kind of bugs that I want to early detect and that I find quite difficult to find in extense projects with multiple variables. Regards, > {Original Message removed}

Tamas, You're looking for run time analysis. There's lots of software for the PC world to do such testing, as you point out. If you're code is written in C then it's not terribly painful to port it and write additional code (test cases) that simulates the I/O and peripherals. Alternately you can use MPLAB's simulator (or any of the other PIC simulators) to perform such testing. If you can port it to the PC, though, you can use all sorts of tools to check the code functionality - array bounds checking, data flow, control flow, coverage, etc. But in the end it's all about how thorough the test cases are. A good static analysis will point out areas to look in. -Adam On 9/26/07, Tamas Rudnai <EraseMEtamas.rudnaispam_OUTTakeThisOuTgmail.com> wrote: {Quote hidden}> Hi, > > Give one or two devices to students and tell them the firmware is super > unbrakable and no way to fail it - and wait couple of hours :-) > > Tamas > > > On 9/26/07, Mauricio Jancic <listasspam_OUTjanso.com.ar> wrote: > > > > Hi, > > I need to implement some secure, safe testing procedure for my > > firmware. So far, I have manually looked at every function, but that might > > miss some combination of events that might present a possible failure. > > > > I would like to know if there is a know method to effectively test > > and diagnose the status of features in firmware (programmed in C or > > assembly). > > > > Thanks, > > > > Mauricio Jancic > > Janso Desarrollos > > Microchip Design Partner > > http://www.janso.com.ar > > @spam@infoKILLspamjanso.com.ar > > (54) 11-4502-2983 > > > > > > --

wouter van ooijen wrote: >> I have been working in my spare time on a way to use ONE pin as a >> bidirectional debug tool >> > > There a is one-pin bi-directional software UART in my WLoader firmware. > > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > > > I remembered that, but I'd never looked closely at it. Got PIC code samples? That might be a VERY good idea as a debug tool. Since each PIC is slightly different, for what PIC's have you written PIC code? Also, since it is a UART, can you use internal RC oscillators, since some PICs have very imprecise oscillators? But I could switch to manchester code, which can tolerate a 25% clock rate difference (between bits, not within a bit) without incurring errors. Really, there are only two commands of any use: (1) read an internal register, including EEPROM; and (2) ability to CHANGE the value of a register, including EEPROM. --Bob Axtell

> > There a is one-pin bi-directional software UART in my WLoader > > firmware. > > > I remembered that, but I'd never looked closely at it. Got PIC code > samples? no samples, just the code itself. and it is for a 20 Mhz 16F877 only. check http://www.voti.nl/wloader/index.html BTW the picture is by Madalina, Vasile's daughter. > since it is a UART, can you use internal RC oscillators, > since some PICs > have very imprecise oscillators? probably not, or at least not reliable under all circumstances. > Really, there are only two commands of any use: (1) read an internal > register, including EEPROM; > and (2) ability to CHANGE the value of a register, including EEPROM. All I have is a bootloader, but it does demonstrate 1-pin bi-directional communication (hardware and software). Actually very simple, the host (PC) just has to live with eho's of everything it sends. Of course 1 pins only sounds sexy until you've seen 0-pin communication. but I did not get that bi-directional. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

back to the original question. Thats a tough thing...keeping track of everything to test and what could fail. I think we all have been bitten by some register overflowing and missing it. Suggestions? 1. keep a list of all timers when where they are used. I usually do my timing inside the ISR and set a flag when it overflows or reaches a value. That way if you happen to miss it in the main body, there is a flag thats set. 2.always use labels. Back in the day...and I know some still do it.... goto $+3 was great. That can bite you tho..so use a label, and be creative...I hate when I have to fix code with labels called aaa,aaaa,aaaaa,aaaaaaa, pure sloppy programming. 3. for error conditions...where your code branches due to some external or programmed error condition....aka...alarms.....if code space allows, separate alarm routines so if you halt on an alarm, you know where it came from. 4. flags. Registers called like "ErrorReg' that have the 8 bits for flags...NEVER just use ErrorReg,0 but again use labels. That way you wont find yourself 'reusing' a flag when you forgot it was already used. How do you check? comment it out where you declare...assemble...and you see every place that its used since it will error on the build. Allows you to verify that you have the right flag being set, checked or reset. 5. Read it. Step by step go thru it...amazing how many dumb things you find where you moved a piece of code or inserted something and forgot how it affected something later. I write in modules, such that you know whats going in..whats going out...and what can affect it. That way you can exercise just the module by writing some simple thing that can exercise it. Allows you to range variables to the module or routine to make sure that it accepts a full range. Those are just some of the things I came up with. Maybe we ought to start a page on the piclist.com for these ideas (unless its there already). --------------------------------- Need a vacation? Get great deals to amazing places on Yahoo! Travel.

This is a very good question actually. In the embedded world we have assembly and C. For the C language we can port them over...... But need to be careful and sensitive to the data range. Example the size for int. If the application is written for PIC assembly it does not provide support for verification on the PC. Running through the debugger does not help when you want things to be automated! John --- "M. Adam Davis" <KILLspamstienmanKILLspamgmail.com> wrote: {Quote hidden}> Tamas, > > You're looking for run time analysis. There's lots > of software for > the PC world to do such testing, as you point out. > If you're code is > written in C then it's not terribly painful to port > it and write > additional code (test cases) that simulates the I/O > and peripherals. > > Alternately you can use MPLAB's simulator (or any of > the other PIC > simulators) to perform such testing. > > If you can port it to the PC, though, you can use > all sorts of tools > to check the code functionality - array bounds > checking, data flow, > control flow, coverage, etc. > > But in the end it's all about how thorough the test > cases are. A good > static analysis will point out areas to look in. > > -Adam > > On 9/26/07, Tamas Rudnai <RemoveMEtamas.rudnaiTakeThisOuTgmail.com> > wrote: > > Hi, > > > > Give one or two devices to students and tell them > the firmware is super > > unbrakable and no way to fail it - and wait couple > of hours :-) > > > > Tamas > > > > > > On 9/26/07, Mauricio Jancic <spamBeGonelistasspamBeGonejanso.com.ar> > wrote: > > > > > > Hi, > > > I need to implement some secure, safe > testing procedure for my > > > firmware. So far, I have manually looked at > every function, but that might > > > miss some combination of events that might > present a possible failure. > > > > > > I would like to know if there is a know > method to effectively test > > > and diagnose the status of features in firmware > (programmed in C or > > > assembly). > > > > > > Thanks, > > > > > > Mauricio Jancic > > > Janso Desarrollos > > > Microchip Design Partner > > > http://www.janso.com.ar > > > TakeThisOuTinfoEraseMEspam_OUTjanso.com.ar > > > (54) 11-4502-2983 > > > > > > > > > -- >

On 9/27/07, Mauricio Jancic <RemoveMElistasTakeThisOuTjanso.com.ar> wrote: > I'm familiar with the tools and things we can to to trace bugs, but I'm > looking for a way to make those bugs appear on my projects. > > For example, a few years ago, we found a very stupid bug on one of our > products. There was a call to DelayS( time ); and if time was cero, the > delay will count 256 seconds. > > These are the kind of bugs that I want to early detect and that I find quite > difficult to find in extense projects with multiple variables. > It seems to me not easy to find a good tool to write good test cases to cover for all (or most) cases. There may be quite some software testing tools for PC or large embedded sytem but I am not familiar with them. Last time we used a simple method (whitebox and blackbox testing) and it normally two or three people (the firmware developer, another firmware developer and sometimes the test engineering people). Xiaofan

Mauricio Jancic wrote: {Quote hidden}> Hi Bob, and thanks. > This is not quite what I meant to ask. > > In the software industry, for desktop computers or systems that don't have > "limited" resources, you can use Test driven design, which, according to > WikiPedia means: > > "Test-Driven Development (TDD) is a software development technique that > involves repeatedly first writing a test case and then implementing only > the > code necessary to pass the test. Test-driven development gives rapid > feedback. The technique began to receive publicity in the early 2000s as > an > aspect of Extreme Programming, but more recently is creating more general > interest in its own right" > > I'm familiar with the tools and things we can to to trace bugs, but I'm > looking for a way to make those bugs appear on my projects. > > For example, a few years ago, we found a very stupid bug on one of our > products. There was a call to DelayS( time ); and if time was cero, the > delay will count 256 seconds. > > These are the kind of bugs that I want to early detect and that I find > quite > difficult to find in extense projects with multiple variables. I missed this thread the first time (thanks Sean! :). We haven't done any test-driven development yet, but we are planning to do our next project that way. They talked about TDD at the Agile project management seminar I attended early this year, and I understood that it was part of Agile and supposedly a good thing, but only recently I began to understand what it's about. My biggest misconception was that the tests are something external to the project, like a script that goes through my code and locates the problems. While there are solutions out there that do that, I think the intent is to have the test routines be a part of the project (just another unit, test.c). So with TDD, you write the test first, and make sure it fails (since the unit it's supposed to be testing hasn't been written yet). Then, you write the unit, run the test, and make sure it passes. Then you write another test, and the cycle repeats. Eventually, you have a bunch of tests that test all the code in the project, so you can make changes to the code without worrying too much about introducing bugs (if you make a bug, it should be caught by one of the tests). For example, say you need to write a function that would calculate the CRC byte. You begin by writing the test routine, which would provide some data to the CRC function, and verify the return value. You run it once to make sure it fails, then write the code for the CRC function. One big advantage of this approach, is that it promotes loose coupling and tight cohesion, as well as forcing the programmer to "code for testability" -- much easier to do, than writing tests at a later time, for code that's been written with no regard for testability. It may not be practical to automate everything, so in some cases you may still need to have a human tester perform the test. For example, you can have the test routine output some data on RS232, and have the tester verify the output visually. Or generate a waveform, and check it with a scope. I'm sure I'll have more examples as I gain more experience. :)

On 9/26/07, alan smith <EraseMEmicro_eng2yahoo.com> wrote: > 2.always use labels. Back in the day...and I know some still do it.... > goto $+3 was great. That can bite you tho..so use a label, and be > creative...I hate when I have to fix code with labels called > aaa,aaaa,aaaaa,aaaaaaa, pure sloppy programming. I am curious about one thing. If you use a label, instead of $+n, does the assembler 'translate' GOTO Label into GOTO $+n ?? I am curious about one thing. Let's say I want to skip some code. The easy way out would be to GOTO $+n, which I agree can become rather chaotic. If I where to define a label AFTER the code I want to skip, and use a "GOTO label", rather than "GOTO $+n", does the Assembler translate the "GOTO Label" into a "GOTO $+n"? Sean.

Hi, You might want to look at the following LINK: http://research.microsoft.com/users/pg/ BEN> Date: Thu, 1 Nov 2007 04:08:32 +0100> From: RemoveMEdev.seantechEraseMEEraseMEgmail.com> To: RemoveMEpiclistspam_OUTKILLspammit.edu> Subject: Re: [PIC] How to test> > On 9/26/07, Mauricio Jancic <RemoveMElistasTakeThisOuTspamjanso.com.ar> wrote:> >> > Hi,> > I need to implement some secure, safe testing procedure for my> > firmware. So far, I have manually looked at every function, but that might> > miss some combination of events that might present a possible failure.> >> > I would like to know if there is a know method to effectively test> > and diagnose the status of features in firmware (programmed in C or> > assembly).> >> >> How about Fuzz-testing it all. I wouldn't call it a safe testing method, but> I guess that it could be called 'rather-effective' :> http://en.wikipedia.org/wiki/Fuzz_testing> > Sean.>

> I am curious about one thing. Let's say I want to skip > some code. The easy > way out would be to GOTO $+n, which I agree can become > rather chaotic. If I > where to define a label AFTER the code I want to skip, and > use a "GOTO > label", rather than "GOTO $+n", does the Assembler > translate the "GOTO > Label" into a "GOTO $+n"? 1. What's it to you? :-) ie Regardless of what an assembler or compiler does, it doesn't mean that you should do it manually yourself. Its job is to keep track of detailed relationships and apply them precisely. YOUR job is to make sure that you DON'T do that, even if you think you can, because one day you'll fail to do so inadvertently. 2. Depends on optimisation and actual instruction. At the barest level, if you use a "JMP" instruction to a label then the assembler will use the corresponding command. In practice a processor may have some or all of plus others as well - - jump relative to current location using 4 bit offset - jump relative to current location using 8 bit offset - jump to absolute address in current page - jump to absolute address in whole memory space - other. An assembler with any sort of optimisation may work up all or part of this hierarchy depending on what is needed. As assembler without optimisation that selects the instruction that matches what you actually tell it will "break" if you add code that makes the jump/relative-jump too long or untenable for some reason, and require you to fix it manually. So, the short answer to the question is - "it may or may not depending on the tool and applicable circumstances". Russell

Sean Schouten wrote: > I am curious about one thing. If you use a label, instead of $+n, does the > assembler 'translate' GOTO Label into GOTO $+n ?? No, they will not be translated in that way. But they will both end up in the same machine instruction, yes. The actual instruction is og course "GOTO this fixed address". See GOTO in the doc's. But the point is that if you add something between the GOTO and the target of the GOTO, MPASM will recalculate the offset for you if you use a label, if not (using the $+n method) you have to do any adjustments your self. And you will probably make errors more often then MPASM does... :-) Jan-Erik.

On 11/1/07, Jan-Erik Soderholm <EraseMEjan-erik.soderholmspamspamBeGonetelia.com> wrote: > See GOTO in the doc's. I was glad Microchip finally implemented the comefrom, after having the goto all these years. Still inadequate and kludgy, but it's very usefull. Would be nice to have a real comefrom instruction... -Adam -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Moving in southeast Michigan? Buy my house: http://ubasics.com/house/ Interested in electronics? Check out the projects at http://ubasics.com Building your own house? Check out http://ubasics.com/home/