Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 11 of 11

Thread: Firmware quality

  1. #1
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    919

    Firmware quality

    Say you (or a customer) want assurances of better quality embedded code. What can be done other than "be careful" and "lots of unit testing"?

    Follow most of the MISRA standard? Do something like this to measure code coverage during testing?

    https://mcuoneclipse.com/2014/12/26/...-gcc-and-gcov/

    The above modifies the code produced - I can imagine alternatives involving the automated use of a debugger.

    Much of quality is "I know it when I see it", but that doesn't satisfy a customer looking for something more specific.

  2. #2
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    663
    The most rigorous standards I know of typically require at least two separate coding teams, one writing the code and the other independently reviewing it against the requirements.

    You can also set requirements like "No dynamic memory allocation" and check code size against available memory.

    Unit and systems level testing, ensuring full-coverage of the paths.

  3. #3
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    919
    > "No dynamic memory allocation"

    Having just found a bug similar to below, is there a way to prevent this? Say a gcc option that warns if there is ANY use of the address of a stack variable? I suppose there is "switch to Rust".

    Code:
    int *p;
    
    void foo()
    {
            int i[5];
            p = i;
            return;     // bug!  i will no longer exist - was supposed to be "static int i[5];"
    }

  4. #4
    Senior Member
    Join Date
    Jul 2020
    Posts
    1,042
    Did you run lint?

  5. #5
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    919
    Lint is a good idea. gcc -fsanitize=address also works well on the PC (at execution time) - not clear what would happen with the teensy.

  6. #6
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    663
    Quote Originally Posted by jonr View Post
    > "No dynamic memory allocation"

    Having just found a bug similar to below, is there a way to prevent this? Say a gcc option that warns if there is ANY use of the address of a stack variable? I suppose there is "switch to Rust".

    Code:
    int *p;
    
    void foo()
    {
            int i[5];
            p = i;
            return;     // bug!  i will no longer exist - was supposed to be "static int i[5];"
    }
    Note, I haven't tried either of these, but there's a couple options that I see on Stack Overflow:
    1. Remove the _sbrk() function:
    https://stackoverflow.com/questions/...ory-allocation
    2. Use --wrap to have malloc call a different function and leave it undefined:
    https://stackoverflow.com/questions/...rely-on-an-mcu

    They both take the same approach, resulting in malloc / new being undefined and throwing an error if used.

  7. #7
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    919
    Particularly concerning is that dangling pointers often continue to work, passing lots of tests. Don't cause the next $100+ million mistake:

    https://www.laserfiche.com/ecmblog/w...e-bug-history/

    Not clear what it would take to get -fsanitize=address to work on a teensy. In some cases, unit testing subroutines on a PC might work.

  8. #8
    Senior Member brtaylor's Avatar
    Join Date
    Mar 2016
    Location
    Portland, OR
    Posts
    663
    So, I just tried clang-tidy on your code snippet and it does produce a warning that the code will result in a dangling reference.

  9. #9
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    919
    I tried splint (like lint) on a complete teensy program and it had one parsing problem after another. Might take considerable work to make teensyduino code splint compatible.

    So I'm not aware of a practical solution for catching such errors (in a typical teensy program).
    Last edited by jonr; 06-14-2021 at 05:08 PM.

  10. #10
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    14,143
    Leaving the INO empty and coding into a .cpp file in the folder and completing the needed includes and prototypes might present a valid usable source file, where the IDE build preprocesses that in behind the scenes from what is not an otherwise valid .cpp source file.
    Last edited by defragster; 06-15-2021 at 01:40 AM. Reason: spellcheck

  11. #11
    Senior Member
    Join Date
    May 2015
    Location
    USA
    Posts
    919
    I tried various things and didn't find a usable solution for my error. Probably a port of this is the way to go:

    https://mcuoneclipse.com/2021/05/31/...rocontrollers/


    The teensyduino code would be improved by running cppcheck on all of it. Not hard to do.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •