USB CDC and the 18F97J94 Family

DannyScott · Post by **DannyScott** » Mon Sep 09, 2013 2:56 pm

I am trying to get a USB CDC to run on the PIC18F67J94 (relatively new 97J94 family) using Jerry Messina and John Barker’s stack V1.42. I have searched the forum, but I nothing has come to light apart from the fact that the problems are normally hardware and not software stack related, so I thought I would summarise my efforts.

The code compiles and works beautifully with a PIC18F46J50 FS USB demonstration board (RS 672-2731)

Our bespoke hardware with the PIC18F67J94 runs the Microchip stack as a CDC and all works well, so I am more than optimistic that there are no significant problems with our hardware, however we are desperate to use the BASIC stack as both myself and my colleague find the language far more intuitive than C.

I have generated a PIC18F67J94.bas file using the utility provided and I have added code to the existing stack to accommodate this processor.

Usbsfr.bas:- Added PIR2, PIE2 and IPR register bit field definitions, added an entry for specific 67J94 USB register locations and enabled the correct PLL bit for the 67J94

USBmem.bas :- Added a memory definition for the 67J94 (which I am still not sure is correct) although I have tried numerous different values in both this file, and the 18F67J94.bas (_maxram, _ram_banks) file, comparing this to the other data sheets and supported processors for guidance.

Main_cdc.bas :- Added fuse settings and init_pic routine for our specific hardware / processor.

The code compiles, and I have checked the clock speed with the User_check_clock() subroutine and I am happy that the clock speed is 48MHz.
I am now stuck as Windows reports an ‘Unknown Device’ and I am unsure how to continue. Am I missing something obvious? Has anyone else had any success with this processor?

Jerry Messina · Post by **Jerry Messina** » Mon Sep 09, 2013 5:39 pm

I haven't tried any of the J94 parts yet, but USB-wise from the looks of things the closest part would be the 47J53.

Compare the changes you've made to what's used for that one, and see if it makes sense. Which version of MPLAB did you use to generate the device files from?

The clocking scheme looks to be similar, but it's worth double checking. If you set the main CPU clock postscaler to div by 1 (sets CPU to 96MHz/1.5= 64MHz) using CPDIV<1:0> = 00, then the USB clock should be 48MHz

DannyScott · Post by **DannyScott** » Tue Sep 10, 2013 11:44 am

Many thanks for your reply Jerry.

We are using MPLAB V8.90 and I am pleased to say we used the 47J53 as our reference model as well.

I am having some other quite fundamental problems with this silicon at the moment (my latest post), despite having been doing this sort of thing for 20+ years, and I think it may be an idea to resolve this issue first as it may be masking another underlying problem.

Jerry Messina · Post by **Jerry Messina** » Tue Sep 10, 2013 3:10 pm

Danny -

I just happened to notice a discrepancy in the endpoint register mapping in some of the previous MPLAB versions (and I'm not sure which version of MPLAB they apply to as I keep source archives based only on MPASM versions, not the full MPLAB)

In the device file, make sure the UEPn regs are mapped as follows:

Code: Select all

public system
   UEP0 as byte absolute $0DFF,
   UEP1 as byte absolute $0E00,
   UEP2 as byte absolute $0E01,
   UEP3 as byte absolute $0E02,
   UEP4 as byte absolute $0E03,
   UEP5 as byte absolute $0E04,
   UEP6 as byte absolute $0E05,
   UEP7 as byte absolute $0E06,
   UEP8 as byte absolute $0E07,
   UEP9 as byte absolute $0E08,
   UEP10 as byte absolute $0E09,
   UEP11 as byte absolute $0E0A,
   UEP12 as byte absolute $0E0B,
   UEP13 as byte absolute $0E0C,
   UEP14 as byte absolute $0E0D,
   UEP15 as byte absolute $0E0E,

In some versions these are backwards!

DannyScott · Post by **DannyScott** » Wed Sep 11, 2013 12:38 pm

Jerry -

The UEP addresses are correct in the device file.

Any further thoughts in view of our recent findings regarding some of the SFR's existing outside of the access bank in this processor? (the UASRT2
print problem)

I appreciate it is only inline .asm statements which caused the previous problem but I thought I would ask the question anyway.

Alternatively do you have any ideas how I can proceed?

DannyScott · Post by **DannyScott** » Wed Sep 11, 2013 1:22 pm

Jerry -

I also thought it may be important to mention that we are using MPASM V5.49 (not V5.42 which ships with SF) as the earlier version complains about an unknown processor.

Jerry Messina · Post by **Jerry Messina** » Wed Sep 11, 2013 1:56 pm

>>may be important to mention that we are using MPASM V5.49

That's always good to know. I'm using V5.51, but there doesn't seem to be much difference for the 18F series from what I see.

>>Any further thoughts ...regarding some of the SFR's existing outside of the access bank

I don't think that's an issue (being optimistic)... I've used other chips that have registers outside the Access bank w/out problem. As long as the device file has the memory layout set properly, SF takes care of this (inline asm aside).

Jerry Messina · Post by **Jerry Messina** » Wed Sep 11, 2013 3:50 pm

Two things popped into mind, and they're worth checking out.

First thing is that I goofed up and inadvertently left some debug code in the CDC ISR in usbcdc.bas:

Code: Select all

interrupt USB_intr_handler(PRIORITY_LEVEL)
high(porta.0)                // <<<< REMOVE THIS
    // check for USB intr request
    if ((PIR2Bits.USBIF = 1) and (PIE2Bits.USBIE = 1)) then
        PIR2Bits.USBIF = 0
        save(0, FSR0, FSR1, _service)
        _service()
        restore
    endif
low(porta.0)                // <<<< REMOVE THIS
end interrupt

Secondly, there are some IO pins that can be used for sensing USB power, etc (USB_BUS_SENSE_IN), and these can be problematic.

If you're using them make sure they're correct and set to digital mode since most of the J series pins default to analog mode (and always read 0). The J94 uses ANCONx registers for this, and they're prob. not being setup by the USB code.

Jerry Messina · Post by **Jerry Messina** » Sun Sep 22, 2013 1:05 pm

For anyone interested in this thread, I've been working w/Danny on this trying to get this working for the J94 series.

There are a number of bits that have changed location (such as PLL bits changing registers), so some of the code no longer works w/out modification.

However, the biggest issue I've run across is the fact that the DATASHEET IS WRONG!!!!! It says that the USB BDT memory is located in Bank 13 at $D00, and it isn't... it's located in Bank 1 at $100.

It's taken me days to get this figured out. I could never get the darn thing to enumerate. Only today when I went searching though the latest Microchip USB stack source code did I find this little nugget hidden away in one of the header files (usb_hal_pic18.h)

Code: Select all

//----- Defintions for BDT address --------------------------------------------
#if defined(__18CXX)
    #if defined(__18F14K50) || defined(__18F13K50) || defined(__18LF14K50) || defined(__18LF13K50)
        #define USB_BDT_ADDRESS 0x200     //See Linker Script, BDT in bank 2 on these devices - usb2:0x200-0x2FF(256-byte)
    #elif defined(__18F47J53) || defined(__18F46J53) || defined(__18F27J53) || defined(__18F26J53) || defined(__18LF47J53) || defined(__18LF46J53) || defined(__18LF27J53) || defined(__18LF26J53)
        #define USB_BDT_ADDRESS 0xD00		//BDT in Bank 13 on these devices
    #elif defined(__18F97J94) || defined(__18F87J94) || defined(__18F67J94) || defined(__18F96J94) || defined(__18F86J94) || defined(__18F66J94) || defined(__18F96J99) || defined(__18F95J94) || defined(__18F86J99) || defined(__18F85J94) || defined(__18F66J99) || defined(__18F65J94)
        #define USB_BDT_ADDRESS 0x100		//BDT in Bank 1 on these devices
    #else
        #define USB_BDT_ADDRESS 0x400     //All other PIC18 devices place the BDT in usb4:0x400-0x4FF(256-byte)
    #endif
#endif

Thank you Microchip!

After making the req'd change I've now got it running, but since the USB BDT sits so low in memory the code on the site is limited to 256 bytes of ram since I never posted how to modify it to use the protected block feature introduced in SF 2214

David Barker · Post by **David Barker** » Sun Sep 22, 2013 2:08 pm

Hi Jerry

I'm really sorry to hear you wasted so much time on an incorrect datasheet - as a software developer I really do understand how frustrated and annoyed you must be feeling. However, it's fantastic news that you have this up and running. Will you be posting an update of the code on the wiki at some point?

Jerry Messina · Post by **Jerry Messina** » Sun Sep 22, 2013 2:57 pm

>> I'm really sorry to hear you wasted so much time on an incorrect datasheet

You'd think I would know better by know. Oh well.

>>Will you be posting an update of the code on the wiki at some point?

I intend to, but before I do that it needs some clean up, and I'd like to revamp it just a bit to incorporate the protect blocks feature, and add a few bug fixes.

The protected blocks make it much easier than fooling around with all the "EXTENDED_RAM" mumbo-jumbo. I know that's got to be confusing to folks since it still makes me think every time I go to use it. I have to double-check, but I seem to recall that once I used the protected regions there really wasn't much need for extended ram unless you were really trying to squeak out every last byte.

Plus, there's one or two other devices that aren't yet supported... some K50 devices I think it was. I picked up an eval board for them when I got the J94 module, but I think I'll do a little more investigating first this time!

Jon Chandler · Post by **Jon Chandler** » Sun Sep 22, 2013 10:58 pm

Thanks for all the effort Jerry!

DannyScott · Post by **DannyScott** » Mon Sep 23, 2013 12:45 pm

Jerry

I am very happy to report that we have the stack running a CDC on our PCB's now.

I wish manufacturers would put a little more effort into getting their datasheets correct!

Sincere thanks for all you hard work in resolving this.

DannyScott · Post by **DannyScott** » Mon Sep 23, 2013 1:15 pm

Jerry

I am very happy to report that we have the stack running a CDC on our PCB's now.

I wish manufacturers would put a little more effort into getting their datasheets correct!

Sincere thanks for all you hard work in resolving this.