Code coverage

Log in or register to post comments
Go To Last Post
10 posts / 0 new
Author
Message
ufechner
ufechner's picture
Level: Wannabe
Joined: Thu. Feb 13, 2003
Posts: 95 View posts
Location: Kiel, Germany
#1
Posted by ufechner: Fri. Nov 2, 2007 - 02:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hallo,

we are developing medical devices and need to prove curtain code coverage (e.g. statement coverage or branch coverage) of our tests.

With the older emulator e.g. ATICE50 this was possible because of the big trace memory.

But the new AVR devices, e.g. ATmega328 or ATmega1281 are not supported by this emulator.

We have a complex realtime system with four CPU's from different vendors, therefore it is difficult to use simulation to prove the code coverage of our testsuite.

Does this mean, we have to avoid the new AVR chips for our future designs?

Regards:

Uwe Fechner

Tags:

AVR Microcontrollers, megaAVR and tinyAVR, ATmega128, ATmega1281, ATmega32, ATmega328
Top
ufechner
ufechner's picture
Level: Wannabe
Joined: Thu. Feb 13, 2003
Posts: 95 View posts
Location: Kiel, Germany
Posted by ufechner: Fri. Nov 2, 2007 - 05:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, for the moment I see two possibilities:

1. For small projects, I can add a function call, that sets a
bit in a big bitfield for each possible path.
In a project with 2000 lines of code, I might have 200
possible execution paths.
Than I would need 25 bytes, to keep record of the
information, which paths have been executed.

2. For bigger projects, I might use tha AVR32 MCU's.
They have a debug port, which shall be able to provide
a program trace in realtime.
(Well, the IAR debuger doesn't seam to support this,
yet).

Regards:

Uwe Fechner

Top
Bronze Markbobgardner
bobgardner's picture
Level: 10k+ Postman
Joined: Wed. Sep 4, 2002
Posts: 26609 View posts
Location: Orlando Florida
Posted by bobgardner: Fri. Nov 2, 2007 - 05:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely a 4 processor design with 4 of the SAME computers would be simpler/easier/less risky than a design with 4 different computers?

Imagecraft compiler user

Top
ufechner
ufechner's picture
Level: Wannabe
Joined: Thu. Feb 13, 2003
Posts: 95 View posts
Location: Kiel, Germany
Posted by ufechner: Fri. Nov 2, 2007 - 06:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No, that's not true. The german control authorities are always happy to hear, that we use different MCU's, as this makes it less likely, that more than one MCU fails for the same reason.

At Hagen university we learnt, that a good (and comparetivly cheap) way to achive diversity between units, that control each other is to use different compilers and libraries.

So, the most easy solution (identical MCU's with just one compiler) is not the least risky solution.

In the moment I think, we will always need three different type of MCU's: One with a high speed PWM for charge control, one small CPU type for motor control and one big cpu type for all of the rest.

If you understand German, you can read my Bachelors theses:
"Optimization of a security related stepper motor control
for portable infusion pumps": http://www.kieltech.de/uweswiki/...

Regards:

Uwe Fechner

Top
Bronze Markbobgardner
bobgardner's picture
Level: 10k+ Postman
Joined: Wed. Sep 4, 2002
Posts: 26609 View posts
Location: Orlando Florida
Posted by bobgardner: Fri. Nov 2, 2007 - 06:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think these safety regulations must be similar to the DO-178B safety requirements for airborne software...

Imagecraft compiler user

Top
EW
EW's picture
Level: Raving Lunatic
Joined: Thu. Mar 1, 2001
Posts: 4914 View posts
Location: Rocky Mountains
Posted by EW: Fri. Nov 2, 2007 - 07:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A quick Google search on "code coverage AVR" came up with a link to VMLab:
http://www.amctools.com/vmlab.htm

I have no idea if it is useful.

Eric Weddington
www.linkedin.com/in/ericweddington/

Top
Kruten
Kruten's picture
Level: Rookie
Joined: Sat. May 21, 2005
Posts: 30 View posts
Posted by Kruten: Fri. Nov 2, 2007 - 09:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There was recently some articles on www.embedded.com that were about "Code coverage on a shoestring"...or something like that. The articles adressed your problem by using clever C preprocessor tricks.

Here is the article: http://www.embedded.com/columns/...

I think it requires some overhead but maybe your AVR can bear it.

Top
ka7ehk
ka7ehk's picture
Level: 10k+ Postman
Joined: Fri. Nov 22, 2002
Posts: 21834 View posts
Location: Tangent, OR, USA
Posted by ka7ehk: Fri. Nov 2, 2007 - 10:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't think that DO-178B required multiple processors The company I recently worked for was developing flight data displays for General Aviation aircraft. This product had a single pentium-class processor. There were also engine sensor interface boxes and nav/com interfaces with single processors, each. There did not appear to be any requirement for redundancy and this system was built to DO-178 and other RTCA/FAA specs.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Top
jfiresto
jfiresto's picture
Level: Resident
Joined: Mon. Oct 7, 2002
Posts: 690 View posts
Location: Germany
Posted by jfiresto: Fri. Nov 2, 2007 - 11:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
I don't think that DO-178B required multiple processors....
That's right. That would be too prescriptive and I doubt there would have been sufficient industry experience at the time it was written to distill a reasonable set of requirements. DO-178B is only now being revised to actually specify what it meant by 100% code coverage. Whereas before, demonstrating 100% object code coverage was acceptable, I understand that is being changed to 100% source code coverage. I need to ask our white-haired simulator guru why that should or must be!

- John

Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 40013 View posts
Location: Wisconsin USA
Posted by theusch: Fri. Nov 2, 2007 - 11:42 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

...demonstrating 100% object code coverage was acceptable, I understand that is being changed to 100% source code coverage.

Hmmm--either way, but especially source, might be quite difficult with an optimizing compiler that tosses out useless source lines and generates no code for them.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top