PIC24FJ256GB106
 
We are driving a pair of LED's with Port B bits B13 and B14. The LED's are a simple operational mode indication. Sourcing about 4 mA per pin.
 
We have been through checking all of the alternate functions of Port B13, Configurations etc without getting any closer to solving our problem.
 
Occasionally, and usually after a minute or two of being powered down the B13 Mode LED does not light. There is NO port drive ( confirmed with a scope AND DVM ) B14 works just great. 
 
We are setting the port TRIS bits to output at boot and leaving them that way.
 
Port bits are manipulated using the MCC generated macros
 
#define LED_R_SetHigh()     _LATB13 = 1;
#define LED_R_SetLow()      _LATB13 = 0; 
#define LED_G_SetHigh()     _LATB14 = 1;
#define LED_G_SetLow()      _LATB14 = 0; 
 
Then we modified stuff to set the pin high, read the pin and if it's low when we expect it to be high go through a bunch of stuff to re-iniitalize the port etc. Non of which works.
 
#define LED_R_SetHigh()          {  TRISBbits.TRISB13 = 0;_LATB13 = 1; printf("1"); if (_RB13 == 0) { AD1PCFGH = 0x0003; TRISBbits.TRISB13=1; TRISBbits.TRISB13=0;_LATB13 = 1; PORTBbits.RB13 = 1; AD1PCFGLbits.PCFG13 = 1;  ODCBbits.ODB13 = 0; CTMUCON = 0; printf("-"); __delay_ms(80);} }
 
 
 
Eventually after a little while ....... PortB 13 comes back to life. but not sure what is changing
 
Driving me nuts! 

Try setting data breakpoints on the TRISB and LAT registers and looking for any unexpected writes to those registers.  If this doesn't work, do the same thing for the more obscure registers such as peripheral pin selects for that pin or the analog select register.

If you haven't used data breakpoints before, I did a video a few weeks back on how to use them to debug odd and unexpected writes.
 
https://www.youtube.com/watch?v=fd_nowHtI7c
 
 

Are you sure there isn't any other code running trying to set a RB# pin by writing to PORTBbits when it should be LATBbits?
 
I can already see your macro is doing this:
_LATB13 = 1; PORTBbits.RB13 = 1
Do NOT write to PORTBbits. That can corrupt all the other pins in the same port.
 

Follow Ric's guidance first.
 
If that doesn't get you anywhere, another thing you might try:  If you aren't using change notification for anything else you could set the Change Notification for that pin and set a breakpoint in the interrupt.  It should go off every time the pin changes state.  The change notification interrupt should return back pretty close to whatever caused your pin to change.  It'd be nice  if you could use an INT instead, but RB13 isn't a PPS pin...

That write to Port B was only in debug after detecting that the output polarity had not changed. Made no difference. There are NO port writes anywhere in the code.
I have trapped this lot and done a scan of ALL the associated PPI selects AND the config bytes and everything appears to be set as it should be.
Writing a routine that runs at start up .... Toggle the output pin, read it, if it doesn't change reset and reconfigure EVERYTHING..... sometimes it gets caught and loops ..... sometimes it runs. Bizarre.
 

If you have written a short but complete app that demonstrates the problem then please post that here (remembering to use the 'code' tags).
Also you probably need to tell us exactly what you have connected to that pin, the power pins etc.. A complete schematic would be good but I know that might not be possible.
Also you need to stop making multiple changes at once - one thing at a time and be methodical in your testing.
Susan