Code coverage

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 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

  • 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

  • 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

  • 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

  • 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

  • 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.

  • 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.

  • 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"!

 

 

  • 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

  • 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.