USB with 18F2550

[RaptorUK]

Using CCS PCH 5.015

I've been lurking here for some time and reading posts, many of which have helped me, but now I think I'm in need of some specific help.

I've recently resurrected a project that I originally worked on at the tail end of 2017, at that time I was using a "Dev" board made by MikroE, I had running code to capture 50 bytes of data sent every 200mS using 9bit RS232 comms, the 9th bit is used to signify the start of the block. I also had I2C working which was used to talk to a RTC and an EEPROM. The 50 bytes of status data was relayed out via the USB to a PC running LabVIEW and TestStand.

Fast forward to today and I now have my own board with the PIC 18F2550 and some other bits and pieces on it which means I have been able to use this board for other projects.

This has been my first PIC coding project, I've not done the best job, I sill have a lot to learn, but I have something which kinda works, sometimes, it's a little flaky and it's this flaky-ness I'm trying to understand and eliminate.

The issue I'm seeing involves the USB "com port" becoming inaccessible and needed a PIC power cycle for it to come back . . . when the USB is inaccessible it is still shown in Device Manager and the PIC is still running, I have red LED that flashes when a status block of 50 bytes is ready, but my LabVIEW code will not see the com port neither will RealTerm . . .



I'm hoping that the fact that the Device Manager still "sees" the device but Realterm and LabVIEW don't will mean something significant to help me fix my issue. I'm not knowledgeable enough with USB to understand what is going on here.


I have recently been wondering if it's a Stack issue but mt .lst file says this . . .

ROM used: 9174 bytes (28%)
Largest free fragment is 23594
RAM used: 699 (34%) at main() level
743 (36%) worst case
Stack used: 18 locations (9 in main + 9 for interrupts)
Stack size: 31


. . . which I think looks OK ?

I originally had my own functions to clear FERR and OERR which I have since removed and am now relying on "ERRORS" in my RS232 stream definition

[Ttelmah]

VREGEN, enables the voltage regulator used to feed the I2C transceivers.
You can run without this, _provided_ you feed 3.3v into the Vusb pin.
If you don't feed this and the regulator is not on, the USB transceivers
won't be getting power. Not surprised it'll be 'flaky'...

[RaptorUK]

[Ttelmah]

I suspect what was happening, was classic for a driver that is not powered.
The internal diodes in the output FET's were acting as diodes when reverse
biased, so the signal on the USB bus would at times charge Vusb up
to only perhaps 0.7v below the voltage it needed....

[RaptorUK]

[Ttelmah]

Have you got 'connection sense' wired and used in the PIC code?.
This is _required_ if the device is not powered by the USB bus.
The CCS notes in the files make it sound 'optional'. It isn't. USB requires
the device to turn it's drivers off, if Vusb goes off. If this is not done, and
Windows puts the USB bus to sleep, it won't wake back up.
You can partially disable this, by in the Windows device manager looking
for the setting for the USB device called 'Selective suspend', and disabling
this. However Windows will still use this if it goes fully into hibernate
mode.
The other thing that can cause an issue for LabView is incorrect settings
in the NI-VISA driver:
<https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P6soSAC>

[RaptorUK]

Thanks for the reply.

[Ttelmah]

Are you calling usb_task reasonably regularly in your code?. Again this is
'required'. Usb_task handles some parts of the housekeeping in USB. It is
what will re-make the connection if Windows does send a disconnect, and
it also ensures some other parts of the interface are kept correctly
synchronised. It must be called occasionally or the interface can get into
an unresponsive state.

[RaptorUK]

[Ttelmah]

OK. That should be alright.
Post your setup (fuses, clock etc..).
Describe your power connection, and the wiring to the USB connector.
Length, how is it connected?.
What smoothing have you got on Vusb, and on the PIC itself.

Your problem sounds as if there is a hardware issue.

[RaptorUK]

Thanks for your help . . . .

[Ttelmah]

You only seem to have a 10uF on the Vbus across the processor. You must
have a smaller non electrolytic capacitor also across this (say 100nF). On
capacitors, 'bigger is not always better'. Electrolytic capacitors give a lot
of capacitance, but have very poor HF performance (up in the MHz range).
Small ceramic or polyester capacitors offer little capacitance, but have really
good HF performance. It is that HF performance, that suppresses the RF
spikes. Essential. This is why you should always have a capacitor like a
100nF, as close to the processor power pins as possible.
Then, why the 33R resistor?. This will be dropping a significant voltage.
If your circuit draws just 20mA, the drop across this would be 0.66v.
If you are worried about safety here just add a small fuse, but get rid
of this resistor.
Then you have 2*100nF for the Vusb. This is low. From the data sheet,
minimum capacitor value is 220nF. _Minimum_.....

[RaptorUK]

[RaptorUK]

[Ttelmah]

I'm confused now. You are talking about some other device?.
You said this unit was powered by the USB.
Is this some other device attached to this part?.