USB on PIC18F45K50 stops working on some chips after some time
The USB firmware is something I botched together closer to 10 years ago from various sources.
The code does not look pretty at all but it has worked for me all that time so I have not bothered to do anything with having been otherwise engaged as they say.
But now I have all of suddenly on some PIC chips the USB stop working in anything from minutes to tens of minutes.
With some chips the identical code runs as long as I have the patience, I just completed a 7 day and night run without problems.
Full disclosure: when I say identical code I cannot be 100% sure, only 99.99% sure because there is a HID mode bootloader that is programmed into the chips using PICKit and the actual software is programmed with the bootloader.
Without reprogramming my working chips with PICKits I cannot be absolutely sure the bootloader is the same on both chips. But I've never changed the bootloader to my knowledge so I'm quite sure they are the same. And I cannot look into the Flash to verify either code because the code protection is on but the bootloader does verify the code during programming.
Now the questions:
Could there be some initialisation or CONFIG settings (which is done in the boot loader source code) that could affect the USB engine so that it eventually fails? This assuming the bootloader code is somehow different in the different chips.
To me this sounds like hardware problem:
all the failing chips are newer and have date code 1718D51 and single working chip has date code 1321VYE.
On failing chip worked for 14 hours but now fails in less than minutes.
I have looked up the silicon errata but there was nothing about USB.
I did find this forum post "forums/m876249.aspx" (I can't post links?)
which seems to indicate that some chips sometime in the past had issues that are not totally different from mine.
But the problem mentioned in above forum thread seems to be that the DTS bit in the DAT register.
AFAIU this is a problem if pingpong buffering is enabled but my code initialises the engine like this (no pingpong enabled):
UCFG = 0x14; // Enable pullup resistors; full speed mode
So the DTS bit should not matter, or what?
Above prompted me to look into my USB code and I discovered that in the actual handling of data stage there is an attempt at pingpong buffering:
if (ep0_i.STAT & DTS)
ep0_i.STAT = UOWN | DTSEN;
ep0_i.STAT = UOWN | DTS | DTSEN;
Like I said it has been many years and I cannot recall where that fragment of code originated. But of course the fault and responsibility is mine ;)
Could that cause problems when pingpong is not enabled?
Could that cause problems in some chips when pingpong is not enabled?