• AVR Freaks

USB on PIC18F45K50 stops working on some chips after some time

Author
nyholku
Junior Member
  • Total Posts : 120
  • Reward points : 0
  • Joined: 2008/04/30 05:13:58
  • Location: 0
  • Status: offline
2020/03/25 12:15:47 (permalink)
0

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;
else
    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?
 
 
cheers Kusti
 
 
#1

4 Replies Related Threads

    nyholku
    Junior Member
    • Total Posts : 120
    • Reward points : 0
    • Joined: 2008/04/30 05:13:58
    • Location: 0
    • Status: offline
    Re: USB on PIC18F45K50 stops working on some chips after some time 2020/03/25 12:17:52 (permalink)
    #2
    Jerry Messina
    Super Member
    • Total Posts : 468
    • Reward points : 0
    • Joined: 2003/11/07 12:35:12
    • Status: offline
    Re: USB on PIC18F45K50 stops working on some chips after some time 2020/03/25 13:34:23 (permalink)
    0

    if (ep0_i.STAT & DTS)
        ep0_i.STAT = UOWN | DTSEN;
     else
        ep0_i.STAT = UOWN | DTS | DTSEN;

    From that code snippet it looks like your code is based on a fairly old version of the mla stack.
     
    I had intermittent problems with the K50 at first until I noticed the following note in the datasheet:
    Note: The firmware should not set the UOWN bit in the same instruction cycles as any other
    modifications to the BDnSTAT soft register. The UOWN bit should only be set in a separate instruction cycle, only after all other bits in BDnSTAT (and address/count registers) have been fully updated.

     
    Older versions of the stack didn't follow that recommendation, but if you look at newer versions of the mla code they do (the UOWN bit is now designated as _USIE in recent code).
     
    Once I changed my code to follow the note, all problems went away.
     
    #3
    nyholku
    Junior Member
    • Total Posts : 120
    • Reward points : 0
    • Joined: 2008/04/30 05:13:58
    • Location: 0
    • Status: offline
    Re: USB on PIC18F45K50 stops working on some chips after some time 2020/03/25 13:42:39 (permalink)
    0
    Thanks! I will try that tomorrow. 
     
    #4
    nyholku
    Junior Member
    • Total Posts : 120
    • Reward points : 0
    • Joined: 2008/04/30 05:13:58
    • Location: 0
    • Status: offline
    Re: USB on PIC18F45K50 stops working on some chips after some time 2020/03/25 23:05:04 (permalink)
    0
    Changed setting UOWN to happen separately, unfortunately it made no difference :( 
    #5
    Jump to:
    © 2020 APG vNext Commercial Version 4.5