ex_usb_serial2.c with 24JF64GB002 but NOT with 24JF128GB202

[Rogier]

I work with USB with 18F etc for years, but now I have a project with a PIC24FJ128GB202 were I want to use an USB thumbdrive bootloader to upload a hex file. But this is a complete other topic. And it doesn't work so far. So I tried to go back to basic and tried to make the USB port work as a device. Just to see what happens.

I compiled the ex_usb_serial2.c example first to an old board from 2014 where I had used a PIC24JF64GB002 (same number of pinnings, more or less the same family)
This example file has a kind of eeprom emulator and a blinking led that blinks at 1Hz.

I use MBLAB v8.92, CCS 5.070

The circuit has no crystal. Should work from internal oscillator. And this works fine. Led is blinking and USB device works fine.

I have this on the usb_common.h (just a portion is shown here)

[Ttelmah]

It initially suggests the USB clock is not being setup correctly.
Now it is interesting that later compilers change the PLL setting from the
one that your compiler uses. Selecting the 4MHz source instead of 8MHz.
However looking through the CLKDIV register settings, these seem to
be correct for the 8MHz selection. Given the 1Hz is running correctly,
the 96MHz is obviously right. The code shows the OSCTUN register being
loaded with 0x9000, which correctly turns on self tune, and selects the
source as being the USB clock. Again correct. So all here looks OK.
Next obvious thought is some peripheral is affecting something about the
configuration on this chip. You don't tell us what pin is being used for the
USB cable detection for example. Though 'nearly' pin compatible, there
are differences like the Vbatt/DISVREG pin, but a problem here would
probably stop the chip working, rather than affecting just the USB.
Post the circuit diagram on the USB connections.
Yes, the 002, is actually out of spec for the USB clock at fast rates.
Rather naughty!... It's 'typical' accuracy is just in the USB specs, so
it most of the time can get away with this, but will cause problems
sometimes...
I was trying to remember if I had any problems with the USB with the
compiler back then. Nothing 'leaping out' though.

[Rogier]

Thanks for your reply

I checked the schematics earlier this morning and it has something to do with the Vbus pin.

I use the SOIC package.
Pin 15 of the 24JF64GB002 is the Vbus pin, this is connected to the 5V of that old board.

Pin 15 of the 24JF128GB202 is the Vbus/RP6/CN24/RB6 pin and I use this for another function than connecting to 5V. If I connect this to 5V (or even 3v3) then it seems to work. I have to go to the code to try to disable need of this Vbus...

My intention is to use the MCU as a device, and only as a host for bootloading.

Thanks for poining me out.

[Ttelmah]

That makes sense. They actually 'recommend' that for slave only you use
Vbus as the connection sense pin. It does feed a comparator in the USB
circuit to 'know' that the voltage is there. I used this ability, and you can
then change the connection sense to testing the VBUSVD bit, rather than
using another pin. That worked well.
Technically a USB device should have connection sense, so using this pin
was the easy way to go. Can you use whatever other pin you use for
connection sense for the other function you require?.
Looking at the code generated, the ALTRB6 fuse is being set to 0, so
the pin should not be using the Vbus functionality.
On the 202, there is no UVCMPDIS bit. Now this is the bit that disables
the VBUS comparators. Now the data sheet specifically says:

[Rogier]

Yes, and it seems that for using the PIC's USB as a device I have to use the VBUS pin (or at least make it permanently high) and I cannot use it for for RP6/CN24/RB6 function...

[Ttelmah]

If you read the USB reference manual for this peripheral, it says that the
non USB related operation is only available when the USB peripheral is
not used. The chip needs Vbus connected when it is a USB slave.
You should not be connecting this to a local 5v., It should only be
supplied from the USB bus. Supplying it from a local 5v supply means
the USB transceivers can be powered before the bus is connected, which
is illegal.