Unit testing on STM32

4
votes

I am looking for advice on how to do unit testing on my STM32F7 platform. What have people done in the past? What horror stories do you have? What would you do differently? What is problematic with my current plan?

My Setup

  • STM32 Nucleo-144 with a custom carrier PCB
  • arm-atollic-eabi-gcc compiler (no C++, for now)
  • Using Atollic TrueStudio as an IDE
  • Development done from Ubuntu 16.04
  • Running FreeRTOS on the board

My Testing Plan

There are different levels of testing; I am specifically talking about unit testing a library / set of functionality that does NOT depend on external hardware. Things like "does my ring buffer implementation correctly handle rolling over without memory leaks" and "does this bit-shift operation result in the correct endianness in the resulting variable"? So I am focused on those kinds of tests.

  • Convert my project to compile with C++ (and all the associated extern C required)
  • Refactor my code into a "library" portion and an "application" portion.
  • Build googletest (this is what we use for other parts of our system) and link my library into it for testing.
  • Run the unit tests on the device while running a debug session through Atollic.
1
stm32nucleostm32f7
Your methods seem fine but I don't think the last part will work. As it requires you modifying googletest to work through a debug session. I would (just as you said) split out the non hardware interfacing layers into libraries and test these externally. – Tarick Welling
@TarickWelling ah good point, I hadn't considered that part of it. – mprat

1 Answers

1
votes

You should revisit the question if you really have to do the unit testing on an embedded target at all as you wrote that unit tests are planned (as usual) in order to test

  • a set of functionality that does NOT depend on external hardware.

  • Things like "does my ring buffer implementation correctly handle rolling over without memory leaks?" and "does this bit-shift operation result in the correct endianness in the resulting variable?"

These are (potential) errors will happen on a PC architecture (x86, ...) in virtually the same way as on STM32.

At the same time, you should ask yourself how many errors will occur accidentally while you

  • Convert [the] project to compile with C++ (and all the associated extern C required)
  • Refactor my code into a "library" portion and an "application" portion.

Don't get me wrong - the latter point may improve the quality of the software considerably if it is done well (and in the ideal phase of the project).

I've been developing software with functional-safety relevance (IEC61508, SIL3) for many years now - and while there might be some special cases when you cannot move all unit testing to a different HW platform (your PC), I have never encountered such an example myself. Instead, we could always perform our unit tests on some PC and complement these unit tests by some sort of integration tests on the original hardware. Please note that in such (complementary) integration tests, you don't have to focus on library-internal logic errors any more, but mostly on HW/SW integration and system integration.