18F4550 Not Recognised

Hi all,

Am i right in thinking D+ on pic connects to D+ on PC and D- to D-, i downloaded the mouse example from microchips site but whenever i plug my f4550 into PC usb the pc says usb device not recognised or might be malfunctioning, i wondered if maybe i got d+ and d- the wrong way round or would it not detect any device at all then, The mouse example comes with the ocs clock set to 48mhz, im useing 20mhz clock so naturally i changed it to 20 but it still does'nt work with either setting.
can someone throw light on the subject?

Thanks
Shaun

i don't feel that 20MHZ clock will be fast enough to provide any USB communication. 40MHZ would work so, you can even use a 10MHZ crystal and set the HSPLL to on. That way, it 'should' work.

But is PLL work great and bug free for that... i can't tell.

Hi Steve,

I've been using 18F452's so this 18F4550 is all new to me, you think 20mhz is too slow? you could be right, should i dump the crystal and use the internal osc, i think i saw in the settings that it had an internal osc, i've built a new dev board just for this controller as the pinout is slightly different to the F452, i've still kept a max232 on the board for serial comms.
I've been looking at the Bootloader for the F452, do you think it would be possible to make it function on the FR4550 with some adjustment, like i said the F4550 is new to me so forgive me if im talking cr*p

Shaun

A 20MHz crystal is fine as long as you set the proper config word options.

Below are my config settings for the 18F4550 from my 18F4550.INC file in my
PBP directory. I have edited the default settings in this PBP header file for
the 18F4550 to be compatible with the Microchip USB boot-loader.

Code:

---

        NOLIST
    ifdef PM_USED
        LIST
        "Error: PM does not support this device.  Use MPASM."
        NOLIST
    else
        LIST
        LIST p = 18F4550, r = dec, w = -311, f = inhx32
        INCLUDE "P18F4550.INC"        ; MPASM  Header
        CONFIG PLLDIV=5,CPUDIV=OSC1_PLL2,USBDIV=2,FOSC=HSPLL_HS,FCMEM=OFF,IESO=OFF
        CONFIG VREGEN=ON,CCP2MX=ON,WDT=OFF,WDTPS=32768,PBADEN=OFF,PWRT=OFF,MCLRE=ON
        CONFIG LPT1OSC=OFF,BOR=ON,BORV=2,STVREN=ON,LVP=OFF,ICPRT=OFF,XINST=OFF,DEBUG=OFF
        CONFIG WRTB=ON
        NOLIST
    endif
        LIST
EEPROM_START        EQU        0F00000h
BLOCK_SIZE        EQU        32

---

PLLDIV=5 ' This sets the PLL Postscaler to divide the primary osc input by 5
providing 4MHz to the 96MHz PLL. The 96MHz PLL input must always be 4MHz
as shown in the data sheet.

CPUDIV=OSC1_PLL2 ' This sets the PLL Postscaler to divide the 96MHz PLL
output by 2 providing a 48MHz clock to the CPU.

USBDIV=2 ' This divides the 96MHz PLL output by 2 providing 48MHz to the
USB core.

FOSC=HSPLL_HS ' This enables HSPLL for high-speed crystal/resonator.

If you plan to use the Microchip USB boot-loader with PBP, then insert this in
the top section of your code;

DEFINE OSC 48 ' 20MHz crystal with HSPLL enabled = 48MHz
DEFINE RESET_ORG 800h ' Reset Vector = 800h When Using Microchip USB Boot-Loader

Thanks Bruce, i shall give it a try and let you know what happens

Shaun

Funky,

How did you make out? When I took my device from the development board to a circuit board, I had similar problems. As Bruce mentioned, a 20Mhz crystal will work good. In fact, I use a 20Mhz resonator on all of my devices because they are subject to more shock and seem to be a bit more reliable. Anyhow, I have found that if the capacitor value is not correct, you will get this error message. Check the cap on Vusb and use something that is more than 400nF. Once I changed this capacitor on Vusb, everything worked great.

Good Luck,

Chris

Thanks to all for their surgestions, im not ignoring anyone, i will post results as they happen, im a bit tied down with work and stuff right now

Well the update is that the chip is now working, not having a >400nf cap lying around i stuck a 330pf in Vusb instead, it's running Microchips, Mouse in a circle demo, looking at the datasheet i would not have expected that one cap to make any difference being where it is situated, but i was wrong,
Thanks to all for your help

Shaun

Hi,

There is a capacitor connected to Vusb in figure 17.10 on page 184 of the datasheet for the PIC 18F4550.

But I can't find any reference to the recommended value, where did you guys come up with 400nF? And how much more than 400nF can we go?

Robert
:)

Ok, I found another thread where Melanie mentions 17.2.2.8:

"The PIC18FX455/X550 devices have a built-in 3.3V regulator
to provide power to the internal transceiver and
provide a source for the internal/external pull-ups. An
external 220 nF (±20%) capacitor is required for stability."

I don't know why people are mentionning 400nF when the datasheet states 220nF, give or take 20%. Either way, I don't have capacitors in this range so I'm stuck for now.

Robert
:)

higher value may be needed if you experiment some erratic connection failure.

As now, 220nF work great for the really few USB stuff i did as now. you can even place two 220nF (0.22uF) in parrallel or a match of to get the value you want in meantime.

Robert.. OT but KGE will move in the next days/months in the old FLY store near the 30. Will be by far bigger :)

400nF comes from experience. I know what the datasheet says but with 220nF, I found the 18F4550 had trouble enumerating. It may have been due to my design and for most people 220nF may work fine but I was just giving my experience. I don't think there is any harm in using a higher value cap.

Did you get something like this when you didn't have the proper capacitor value?

First the device is seen, but then it craps out with an error.

Robert
:)

could be that. probably you should try first to remove all HIDs in the Control panel/System/Hardware/DeviceManager while your unit is connected and then reboot, then retry.

It may also be a Microchip Bootloader problem if you use it. If so, erease the best, reprogram your device without the bootloader, then retry... about now?

If the problem is the Bootloader, be sure you place a pull-up on PORTB.4 and it may solve some problem. When booting, it looks if the PORTB.4 is low to enter the programming mode. So if your pin is floating it may just ruine your life.

I may be out but try this and the capacitor stuff.

Make sure you keep the connection alive every few mSec with the USBSERVICE.

Quote:

---

Originally Posted by mister_e

...

Robert.. OT but KGE will move in the next days/months in the old FLY store near the 30. Will be by far bigger :)

---

Steve, can you give me more details, I don't know the FLY store. If King George Electronics moves closer to the 30 it's great for me, less distance to travel to buy emergency parts (like a 220nF cap).

Robert
:)

Robert, Fly is besing the Golf.... between the St-Bruno shopping center and Boulevard Cousineau.. on the voie de service. It will be done in few days week. In meantime, MasterVox at Longeuil.

I'm not using a bootloader, don't know how.

I have a pull-up on B4.

I have USBSERVICE in the loop, my code was generated with HIDMaker FullSpeed.

I don't have the Vusb cap, I have to go buy a couple values.

Robert
:)

what are the value you have? Any scrapped computer, printer or anything else electronic?

Look for it in there... that's free.. if you don't calculate your time, movement, gas and plah plah plah.

one thing that just spring to mind... what about your main loop?

Is there some USBIN? if so, remove it and just send few data to know.. what happen now?

I use 470nF on all my USB boards, and have never had a problem with any. That's the same value used on the MeLabs and Microchip USB development boards.

In ceramics, I have .001uF, .01uF, .1uF, 1uF and some 18pF, 20pF and 22pF. The others I have are 10uF tantalum and a ton of electrolytics.

Robert
:)

Hi All,
First thanks to everyone, it seems many heads are better than one and in the end i got it sorted.

Firstly, looking at the 4550 datasheet it seems that all the capacitor does is go to ground so in my wisdom i though nahh, dont need it, i guess i was wrong and should have listened to people

Second, i could never figure out capacitor values but i found some on an old redundant soundcard, the value is marked as 331, this capacitor is now in place and the circuit is working fine, i have tried Microchips mouse demo and it worked ok without the need for drivers on the pc, infact it worked better than expected when i plugged it into the bosses iMac at work and laughed at him trying to figure out what was wrong with his mouse for half an hour.
So anyway 331 works for me on 18F4550 @ 20mhz

Shaun

Robert,

The .jpg file you attached can be caused by many issues but from my experience, there are two that come to mind. One, is the capacitor value, which has been widely discussed in this post. The second, is enumeration during the first part of the program. I had one program I wrote a while ago that was very long and two problems can occur from that. Like someone else said, you have to service the USBSERVICE at least every 10 milliseconds (I think). The other part of the problem is having the device enumerate and I had problems due to my code. I put a simple loop at the beginning of my program which looks something like this:

USBInit

for T=1 to 15000

usbservice
pauseus 100
next T

On this specific program, I got the exact same error as you did. My device enumerated correctly about once every 20 tries. When I put this loop in there, it enumerated 100% of the time.

I hope this helps.

Chris

Thanks to everyone!

I just received my order from DigiKey this morning. The 220pF caps didn't work, despite what the datasheet says. :( But the 470pF worked beautifully, man I'm happy I ordered a set of each, just in case. The device is recognized, YAHOO!!!

Robert
:D

Oh well, it was fun while it lasted. I added some input fields in HIDMaker FS and now Visual Basic gives "Cannot load control HIDagent; license not found". I have no idea what's going on now, I don't think I've done anything different. I wrote to TraceSystems in hopes that they are familiar with this error.

Robert
:(

i can't vouch on the FS one... i use the Mecanique one wich work a treat for me.

For everybody who want to debug serial comm like USB or simple COM port, i recommend the use of a USB or COM port sniffer. It act as a spy. using that, you can also do some reverse engineering of a X previoulsy done project OR simply monitor your own. Really usefull, handy and, in some case, save some headaches... at least to me.

There's a ton of those utility here and there. I tested a lot of those before keeping only from HHD Software.

I have USB monitor and HHD Serial Monitor. See those on the link bellow.
http://www.hhdsoftware.com/index.html

I used them since few months now for reverse engineering and project debugger... i love them. Really worth the price you pay for... Even if it can be done easy in VB or else... calculate your hour rate to do it like that... and you'll certainely save money... uneless you charge 1$/hour

Robert,

If your .lic file is not in the same folder as you are trying to complie the program in, you will get this error. Try moving the HIDagentXControl1.lic file to the correct spot and this should correct your problem.

Chris

Thanks C, I moved that file into the folder where all the VB generated files are but I get the same error.

I got a reply from support while I was out, I just have to confirm my license by email and they'll forward the fix. It's supposed to be a simple correction.

I think it's more a matter of putting the entry in that file into the registry, but I'm not going to screw up my system. I'll send my info to support and I should be up tomorrow.

Robert
:)

Yup, I knew it was simple. I now had a copy of the HIDagentXControl1.ocx in another folder. You need that file to make the executable work, but you also need the license file to work on the VB source. Just one of those things that you have to know in PC development, this would probably happen for any ActiveX control.

Excellent support by TraceSystems.

Robert
:)

Quote:

---

Originally Posted by Christopher4187

Robert,

The .jpg file you attached can be caused by many issues but from my experience, there are two that come to mind. One, is the capacitor value, which has been widely discussed in this post. The second, is enumeration during the first part of the program. I had one program I wrote a while ago that was very long and two problems can occur from that. Like someone else said, you have to service the USBSERVICE at least every 10 milliseconds (I think). The other part of the problem is having the device enumerate and I had problems due to my code. I put a simple loop at the beginning of my program which looks something like this:

USBInit

for T=1 to 15000

usbservice
pauseus 100
next T

On this specific program, I got the exact same error as you did. My device enumerated correctly about once every 20 tries. When I put this loop in there, it enumerated 100% of the time.

I hope this helps.

Chris

---

Very sorry to bring up an old post but I've done a lot of searching, head scratching, hardware alterations, firmware alterations etc etc and I still can't get to the bottom of this problem....

I have exactly this problem as described above by Chris and solved it in the same way too. I just can't get my head around why it is happening. I simply can't get my device to enumerate correctly without this loop that he's posted above. With this loop it works fine, but I'm wondering if there's a better way to do it? Something like LOOP until the "Enumerated Correctly" flag is set inside the PIC? Obviously there's not a flag in the PIC called this - that would make it far too easy ;-).

Has anyone else had to perform this kind of loop to enable correct enumeration of the USB?

Again, apologies for bringing this up

P.s. the USBService is being actioned by a timer every 10ms and is being started after this loop

Cheers

Rob

The reason for the error is because if you don't service or poll the usbservice very quickly at startup, it will have an issue. I bet if you looked at your program, it takes longer then 10mS to get to the point where usbservice is included. I believe, and someone with more USB experience then me can correct me if I am wrong, that once the device is enumerated, there can be a longer delay but on startup it must be quick. This post was over a year ago and I haven't corrected the root of the problem. With that small snippet in my code, the device works fine. I guess I have the saying, "If it aint' broke, don't fix it!" Sorry I can't help any further.

Hi Chris,

thanks for the reply, also thanks for your original post in this thread as it was your post that helped me fix this problem in the first place!! I have been using this fix for months but I was just looking to see if there was a better way of doing it. It seems that no-one else has experienced this problem.

Quote:

---

Originally Posted by Christopher4187

The reason for the error is because if you don't service or poll the usbservice very quickly at startup, it will have an issue. I bet if you looked at your program, it takes longer then 10mS to get to the point where usbservice is included.

---

I am definitely servicing the USB every 10ms and I start the timer immediately after USBINIT. I think I will adjust my code so that the USBService is actioned by the timer every 100us for a few seconds on startup and then change back to every 10ms rather than doing it in the loop. This will allow my code to carry on what it is doing and set the USB up in the backgroud again without having to wait around for a second and a half - I'll let you know if it works.

Thanks again

Rob

Hi Chris,

just to confirm that doing the 100us USB Service works from within a timer allowing other operations to continue rather than just looping the USBService. Here is the code from within my service routine (using Darrell Taylor's instant interrupts - damn they're good!):

Code:

---

'*******************************************************************************
'Timer 0 Interrupt Handler: Service the USB
'*******************************************************************************

ServiceUSB:
   
    if usbsetupcount < 15000 then  ' If USBSetupCount has not finished then
        usbservice                  ' Service the USB every 100us
        usbsetupcount = usbsetupcount + 1
        TMR0H = $FF            ' Make Timer 0 hold 65387 so that it takes 100us
        TMR0L = $6B            ' to interrupt each time (Prescale of 8)
@ INT_RETURN
    endif
   
    usbservice                  ' Keep USB connection alive
    TMR0H = $C5                ' Make Timer 0 hold 50537 so that it takes 10ms
    TMR0L = $69                ' to interrupt each time (Prescale of 8)
@ INT_RETURN

---

Thanks very much for the fix - it is massively appreciated (although I should have thanked you months ago!). Hopefully this information will help others!

Rob

Dear All,

I've done some experimenting and found that USBSERVICE must be called at least every 2msec or lower. (10msec is way too long!)

The best way to do this is as Rob suggested, using DT's (Timer0 or1) interrupts.

The above example Rob posted is fine (every 100usecs) but may cause additional overhead for your program. Note, he's using an OSC speed of 48Mhz (PLL) to calculate TMR0H:TMR0L values.

Cheers
Squib

Quote:

---

Originally Posted by Squibcakes

I've done some experimenting and found that USBSERVICE must be called at least every 2msec or lower. (10msec is way too long!)

---

Is that 2ms just for enumerating the device? After I get the device enumerated correctly I've been able to communicate over USB reliably with 10ms services; it's just too long for the enumeration process (in my particular program).

Quote:

---

Note, he's using an OSC speed of 48Mhz (PLL) to calculate TMR0H:TMR0L values.

---

Yeah that's right! Should have said that really.

Cheers

Rob

Hmmmmmm - Squib I think you may be right about your 2ms or less USB Services.

Although I was managing to get my device to communicate reliably after enumeration with longer time periods between the USB Services, I did encounter a problem:

When the PC is turned off, there is still power on the USB which means that my USB device thinks it has just been plugged in. It therefore actions the quicker (100us) USBService for a short time. If the PC is then switched on, the USB device will not be found by my software as it has started issuing the USBService every 10ms. However, if I completely do away with the 100us USBService period and just replace with 2ms as you suggested, the device is found every time.

Thanks for that Squib, you've saved my head from getting sore, either by lots of scratching and/or head to desk contact!!!!

Rob

EDIT: After doing some experimenting I found that 2.1ms works fine, 2.2ms does not, therefore I'm going with Squib's suggestion of 2ms giving a bit of leeway (5%) - Thanks again!

Hi Rob,
did you also tried without timer interrupts? have a look at Darrel's suggestion AKA POST 148
http://www.picbasic.co.uk/forum/show...&postcount=148

This use USB INT instead of a timer interrupt... really cool stuff!

Hi Steve,

damn it - why can't I ever find things like that when I search the forum - that's EXACTLY what I was looking for to see when the device was configured correctly. Thanks VERY much for that link.

Regards

Rob

The thread here is a few years old but I have been seeing something with the 18F4550 that I would like others to review.

I am very new to experimenting with USB and PICs but have a number of excellent tools to help me learn. I run Pic Basic Pro 2.50, HIDmaker, have the book USB complete, write in VB 6.0, use a Melabs U2 programmer, and have the Melabs LAB-XUSB experimental board and a number of PICPROTO-USB prototyping boards populated with 18F4550's.

My preliminary test program worked well on the Lab-XUSB board but I noticed intermittent USB on the Picproto-USB boards. Realized from other discussions that the Vusb capacitor to ground was important but even with the proper capacitor the USB would connect and disconnect continuously every few seconds.

I found that I could eliminate this connection problem by changing one setting in the configuration. The setting is "Low Voltage Programming". If enabled I would have problems and disabled it works great.

This seems a little odd to me and would like to know if others can repeat this and shed some light on this subject.

I have reproduced this with 5 different boards and 5 different 18F4550's.

Bruce
Duluth, MN

I scoped out the power and when looking at Vusb I noticed it was cycling high and low (actually dropping slowly and returning high faster). My connects occurred when the voltage returned high but after dropping to around 3 volts would disconnect.

This is always nice when we have the code (and schematic) to evaluate any kind of potential issue.

BUT leaving Low-Programming mode enabled is a sure way to have some issue one day or another... unless you don't use this pin and set it to GND via a pull-down resistor.

This rule apply to all PIC with Low-Voltage programming mode.