Due to the the nature of the program, I had to use a new pic with the necessary features, 16F18313. This required the switch over to MPLABX v5.35
This is where the weird result comes in, I could not get the debug/step-thro to work, so I set up test jig to debug the PGM, it compiles fine and shows Program/verify complete.
But after getting weird results, I tried two 16f18313 PIC's I had, all showed different results using the same compiled program in run, I tried mixing them around with alternate programming using the same compiled file and all showed different results, but the same chip showed the identical oddity every time,
I am beginning to suspect bad Pics?
Acquired them from Digikey.
.

 

Sounds more like a programming error of some sort.
Just a WAG.
If the problem involves some sort of interaction with SRAM it's possible that power on random bits in parts of uncleared SRAM (cryptographically called a Physically unclonable function) could cause different weird non-deterministic problems on each device of the same type if an error uses that uninitialized memory.

Are you you clearing all SRAM memory at the start of the program? If not, try it to see if that stabilizes symptoms between chips.

 

Due to the the nature of the program, I had to use a new pic with the necessary features, 16F18313. This required the switch over to MPLABX v5.35
This is where the weird result comes in, I could not get the debug/step-thro to work, so I set up test jig to debug the PGM, it compiles fine and shows Program/verify complete.
But after getting weird results, I tried two 16f18313 PIC's I had, all showed different results using the same compiled program in run, I tried mixing them around with alternate programming using the same compiled file and all showed different results, but the same chip showed the identical oddity every time,
I am beginning to suspect bad Pics?
Acquired them from Digikey.
.

The trick is to test small bits of your code at a time, and keep adding code till it don't work no more.

That'll give you a clue where the error is.

As an aside -- and completely off topic -- I noticed the first two bullets on the data sheet:

• C Compiler Optimized RISC Architecture
• Only 48 Instructions

Who give a flying fig how many instructions there are if the architecture is "C Compiler Optimized"? Pffft.

 

Due to the the nature of the program, I had to use a new pic with the necessary features, 16F18313. This required the switch over to MPLABX v5.35
This is where the weird result comes in, I could not get the debug/step-thro to work, so I set up test jig to debug the PGM, it compiles fine and shows Program/verify complete.
But after getting weird results, I tried two 16f18313 PIC's I had, all showed different results using the same compiled program in run, I tried mixing them around with alternate programming using the same compiled file and all showed different results, but the same chip showed the identical oddity every time,
I am beginning to suspect bad Pics?
Acquired them from Digikey.
.

Did you flow-chart your code? Did you walk through your flow-chart testing every possible outcome on paper, first...? Don't _assume_ your code runs right, check it and prove it. Just because a compiler compiled the code, DOES NOT mean the code is right, the logic sound, or even the syntax actually correct. I know I belabor flow-charts, but they are among the most powerful tools in a developer's arsenal.

 

I have ordered a few more Pic's today, so I will do some progressive testing and see what happens!

 

The debug step-through creates its own problems. If your software involves internal flags that are cleared by reading registers (such as the received data flag of a UART, for instance) then the bit will also get cleared when the debugger reads it.

 

New batch of Pic's:
OK , on the ongoing issue with the 16F18313, In order to eliminate as much as possible, I programmed a 12F683 with a LED I/O test program that also used the PWM to fade in and out a LED's.
This was to eliminate a possibility my LED test jig set-up was flaky!
The chip performed as it should.
I tried the 16F18313 again and got inconclusive results, I simply wrote a simple instruction to turn on the three LATA outputs (0,1,2) ON.
At one point one LED did not light, I checked with a meter and the output was zero, the meter caused the led to flash slightly ?
So at this point, I am thinking that the I/O (outputs) of the chip require some internal setting?
This could also explain the various results with this IC so far, where one will light a LED while another does not?
Any setting suggestions ?
Not that it should make a difference, but I programmed the 18313 with MPLABX and the 683 with MPLAB v8.92 !

 

It sounds like the chip does not run correctly. Maybe some power or MCLR issues?

 

So at this point, I am thinking that the I/O (outputs) of the chip require some internal setting?

They all start off as inputs after a reset.

 

One of the first instructions is to set the LATA port I/O.

 

I just made a simple test hex for the chip using XC8. Toggles RA0 fast and RA1 once per second. I don't have the chip so I can't test it for correctness.

#include "mcc_generated_files/mcc.h"

void toggle_RA1(void);

/*
             Main application
*/
void main(void)
{
    // initialize the device
    SYSTEM_Initialize();

    TMR0_SetInterruptHandler(toggle_RA1);
    TMR0_StartTimer();

    // When using interrupts, you need to set the Global and Peripheral Interrupt Enable bits
    // Use the following macros to:

    // Enable the Global Interrupts
    INTERRUPT_GlobalInterruptEnable();

    // Enable the Peripheral Interrupts
    INTERRUPT_PeripheralInterruptEnable();

    // Disable the Global Interrupts
    //INTERRUPT_GlobalInterruptDisable();

    // Disable the Peripheral Interrupts
    //INTERRUPT_PeripheralInterruptDisable();

    while (1) {
        IO_RA0_Toggle();
        // Add your application code
    }
}

void toggle_RA1(void)
{
    IO_RA1_Toggle();
}
/**
End of File
*/

There should be a hex file in the dist default production folder with a ASM listing in the disassembly folder.

A mplabX 6.05 project zip

 

If that's your code, you're toggling far more than once per second.

Edit: sorry, read your text again. Yes, ra0 should toggle quickly.

 

Not Mine?

 

Any update on progress?

 

One main issue was using the Gen Purpose RAM 20h - 6fh , switched to the common RAM 70h-7fh, cured most issues.
Otherwise banksel should have been used with the former.?

 

One main issue was using the Gen Purpose RAM 20h - 6fh , switched to the common RAM 70h-7fh, cured most issues.
Otherwise banksel should have been used with the former.?

Great! My intuition that this was somehow RAM related was at least in the ball park, maybe.