Writing code that can be checked by the lay person (hardware engineer)

Hello
We use PIC microcontrollers.
Our contractor has sabotaged our software so that the product fails after 6 months in the field.
In future, we want the software engineer to write code that is checkable by us. We heard there is a microchip code configurator where the software engineer has to write in understandable routines which are checkable to the lay person (hardware engineer).
The code cannot be sabotaged because only standard microchip routines are inclided, which correspond to the easy-to-understand staements
Is this true? It sounds to good to be true.?
The website doesnt give much away about it

https://www.microchip.com/mplab/mplab-code-configurator

It seems inevitable the need to have someone with programming skills to support the firmware; any suspicion as you raised could be detected by this professional with no difficulty. I have not looked at the above link, but as a rule the simplest programming tools are about to lose some of the most advanced features. In any case, I would not disregard the failure of the equipment to be unintentional, or even due to a problem with the hardware itself.

While it's true the code configurator includes pre-built modules into the code, it does it at source code level so it is still easy to edit it before compiling. It is a utility to speed up the programming process, not to make it more secure.

If you have doubt about the software engineer's motives but you are not confident to check it yourself, get an independent third party to check it over. I will say this though: if the product doesn't have a real-time clock in it or some other method of checking operational time, it's far more likely the failures are due to EEPROM endurance or an electrical problem. A time bomb in software isn't unheard of but unless this contractor is about to go off the radar, they should still be liable for the consequences of their errors and misdeeds.

Do you know what actually stops the product working properly, for example, does replacing the PIC cure the problem every time and what happens if you compare a new and used device, there would have to be a difference in memory contents.

Brian.

The key to understanding code is to have it properly documented. By far, the most important tool are the comments embedded in the code itself.
It should describe the variables, algorithms, I/O ports used, configuration register setup, etc, etc, etc.

schmitt trigger said:

The key to understanding code is to have it properly documented.

Click to expand...

As a friend of mine said, I overly comment my programs to protect them from myself;
:wink:

andre_teprom said:

As a friend of mine said, I overly comment my programs to protect them from myself;
:wink:

Click to expand...

How about:
I add comments to remind myself how smart I was when I wrote it a month ago and no longer remember what I did. :wink:

Testing is a final stage of any development process. Before client will receive the device, it should pass all test in all worse case scenarios.
For example, my last project was compiled from ~40-50 source files, using FreeRTOS and STM32F0x0 mcu. The testing is still ongoing already for 2 month! We did a hw changes and a lot of sw changes according client's requeiments. And this is a part of out job.

No. No No, No No.....

Never add comments - if it was hard to write it should be hard to understand......

Brian.