PIC16F1947 micro is showing noise problems

Hello,
Our microcontroller (PIC16F1947) controlled led driver is showing noise problems (eg it doesn’t work When a scope probe is connected up to it).
We suspect that the software engineer has left some floating pins as inputs.
Can we tell this by looking through his C code at the TRISA, TRISB, TRISC statements etc?
Can the PIC16F1947 have its ports swapped?...eg you can make what’s normally PORTC,5 act as PORTB,2 etc?

PIC16F1947
https://ww1.microchip.com/downloads/en/DeviceDoc/40001414E.pdf

We suspect that the software engineer has left some floating pins as inputs.
Can we tell this by looking through his C code at the TRISA, TRISB, TRISC statements etc?

Click to expand...

In general yes, any bit in a TRIS instruction set to 1 is an input and set to 0 is an output. (think 1nput and 0utput !), but be aware that some internal peripherals need to switch bit direction or logic state as part of normal operation and that may override the TRIS setting.

Can the PIC16F1947 have its ports swapped?...eg you can make what’s normally PORTC,5 act as PORTB,2 etc?

Click to expand...

Except where an internal peripheral has a dedicated pin, yes you can swap them or even swap individual bits between ports in some cases.
That device does not have a Peripheral Pin Select module so unfortunately, it isn't possible to reassign pins on it's package.

Brian.

We challenged the software engineer on why he declared a load of unused pins (PORTC pins) as inputs on the PIC16F1947 (they don’t even have internal pullups).
He came clean and admitted this was a "mistake". -And said he'd correct it.
The thing is, he did this before on us. We had to point it out to him that time aswell.

Once for several months he gave us code that would not work, (but he told us the code was fine and that our “noisy” hardware was making his code fail). …then we told him to bit-bash the incoming data instead of using the DALI libraries, and then the code worked….he had insisted that his code was fine and that our hardware was noisy and making his code go wrong. This turned out to be false, because when we got him to write his code in a simpler way, the product worked fine.
There have been too many “simple errors” with his codes for us. I believe he is deliberately trying to write “borderline” code which makes our products work sometimes and not others….ie….makes it fail intermittently.

Once we read his code and saw a correct line of code which correctly declared pins as either inputs or outputs….but then next to this line, he had a “commented out” line of code which had an incorrect declaration of the inputs and outputs…..next to this he had written “this is the code I will use for the actual product”…I am translating this from his own language in which it was written. When we asked him what he meant by this, he said that this was for a different version of the same PIC which would have needed the different declaration….however, no such “different version” exists.:-?

I believe he is deliberately trying to “throw a spanner in the works” and write dodgy code for us.:shock:

Please tell of ways in which a software engineer can write C code for PIC microcontrollers in order for them to work unreliably…then we can check through his code to see if he has done this. (eg declaring unused pins as inputs etc)

There must be a million ways to write bad code - I know, I tried most of them. Obviously, leaving floating pins is always bad but the proper way to accommodate different types of processor in one source code is to use "#ifdef" directives not to comment lines out. For example:
which tells the compiler it should only process the PORTA = 0x55; instruction if there is a "#define PIC16F1947" statement earlier in the code and only process the other line if "#define PIC16F1948" is present. There is a corresponding "#ifndef" meaning if not defined as well.
The #ifdef/ifndef are used to selectively compile different sections of code depending on which (or both) definitions exist. It is also very useful to turn debugging on and off if you selectively add lines to output debugging information during program development without altering the main program flow.
Note that these are "pre-processor directives", they change the compiled output but can not be used during program execution.

Brian.