easyHID question

[keymuu]

Hi !

Could somebody kindly say, if the use of easyHID is as easy to use as it seems to be, please? Or more precisely, should the outcome work straight away, I mean should the PC say ding-dong when you plug your PIC18F4550 to it and when you unplug it would say dong-ding?

The easyHID generates USBProject.pbp (+5 other files) that are compiled with PBP 2.50b via MicroCode Studio v3.0.0.5 and programmed with meProg, melabs programmer v.4.22 (hardware: melabs U2 programmer). I have moved the generated files to the C:\PBP-folder. On the PC side is the VB-software, but that seems not to be play any role yet...

The generated PIC code does not say ding-dong when plugged, and of course not either dong-ding when unplugged. It does not say anything else either or show any text. You can not either see any changes in control panel/system/hardware/DeviceManager/USB. However if you do it two times (plug/unplug) you need to boot the PC because the used USB-port will be out of order after this until a boot. It's kind of turned off, or invisible. This is kind of strange thing because USB should be rather robust, shouldn't it?

Without USB (USBin etc) PIC works just fine. So the problem lies on the USB side, but where?

The USB connector pins are connected as they shall be:
1=+5V, 2=D-, 3=D+ and 4=gnd.
D- connected to pin 23 and D+ to 24 in series with 22 ohms resistors.

The programmer configuration is:
PLL prescaler "/3 (12MHz)"
System Clock Postscaler "96MHz PLL/2"
USB Clock "HSPLL"

and in the beginning of the generated basic code there are
DEFINE OSC 48
DEFINE LOADER_USED 1

I'm confused with no clue how to proceed from this point. Have tried to look around this thread but haven't found any help.

Anybody, any ideas what could be wrong?
Could somebody point out some info somewhere or perhaps say straight away what one could or should do in this situation.

Please help, any help will be appreciated.

Regards
Key

[Darrel Taylor]

What value capacitor do you have on Vusb (pin 18)?

Are you powering the PIC from the USB power or External power?

I've never seen 22 ohm resistors used before. Normally it's direct wired to the pin.

[keymuu]

What value capacitor do you have on Vusb (pin 18)?

Are you powering the PIC from the USB power or External power?

I've never seen 22 ohm resistors used before. Normally it's direct wired to the pin.

the capacitor on Vusb is 100nF

the power comes from an external source, and as said, it works just fine without the USB...

the 22 ohm resistors are only to give a small additional protection, they should not be harmful for the real work... There is also a SN65220DVB circuit swallowing bigger voltages, for real transient high voltage protection.
Why use condoms if you are sure?

[Darrel Taylor]

If you are using an external power supply, you should not connect the +5 volts to Pin 1 of the USB connector.
Not sure if you meant that in post #1 USB connections.

If you do, it will cause an over current condition, and the USB port will shut-down.

The capacitor should be at least .22uF (220nF).
It may still work with 100nF, but it may also be unstable.

[keymuu]

If you are using an external power supply, you should not connect the +5 volts to Pin 1 of the USB connector.
Not sure if you meant that in post #1 USB connections.

If you do, it will cause an over current condition, and the USB port will shut-down.

The capacitor should be at least .22uF (220nF).
It may still work with 100nF, but it may also be unstable.

I have a schematic that is surely a working system where I can see all the same things (100nF, 22ohm). However I will change the Vusb=100nF to bigger one day, soon... just to be more on the safe side...

The +5V is not connected to USB port, instead USB-connector.1 is connected to PIC portB.5 (pin 38) so the software can detect when the USB cable is connected. There could also perhaps be an USB interrupt possibility, but I thought this would be simpler looked from the program side, on change interrupt or perhaps just polling, ... let's see said the blind man ...

[Darrel Taylor]

220nF is the value recommended in the datasheet.

17.2.2.8 Internal Regulator

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.

The 22 ohms should be fine. I've just never seen them before. Your reference to the SN65220 helped with that problem.

Ok on the +5V.
I prefer to detect the plugged status in a USB interrupt, because it tells you when it's communicating with the computer. The way you have it, it only detects if it's plugged into a port or hub. But that's not going to help the problem at this point.

There are several things that can go wrong here, we'll just have to work through it.

You mentioned before ...
> The programmer configuration is: ...

Are you setting the config's manually in the programmer's software?
If so, is the VREGEN bit enabled? (Turns on the 3.3v regulator)

I assume you've blinked an LED somewhere to verify the oscillator is running at the correct speed.
On these chips, if the main oscillator isn't working, it can switch over to the internal oscillator at a different freq.

[keymuu]

ok, back again....

220nF is the value recommended in the datasheet.

changed the Vusb=100nF to 200nF (added another 100nF), but this did not change anything, no ding-dong sound. Ok one small change, before there was a pop-up window telling that the USB port is not usable. That pop-up window does not come anymore, but the port still dies after the second connection and the PC needs a reboot to come alive again.

The 22 ohms should be fine. I've just never seen them before. Your reference to the SN65220 helped with that problem.

Ok on the +5V.
I prefer to detect the plugged status in a USB interrupt, because it tells you when it's communicating with the computer. The way you have it, it only detects if it's plugged into a port or hub. But that's not going to help the problem at this point.

The USB connection is not a high priority matter, not now and not later either, don't now yet how to implement it...on portB change interrupt perhaps...

There are several things that can go wrong here, we'll just have to work through it.

You mentioned before ...
> The programmer configuration is: ...

Are you setting the config's manually in the programmer's software?
If so, is the VREGEN bit enabled? (Turns on the 3.3v regulator)

The configuration, the mePROG configuration is attached. Where else could one set any configurations, one would think that easyHID could do that job for you... I do not know where that would be...

I assume you've blinked an LED somewhere to verify the oscillator is running at the correct speed.

No LED blinking, however I have verified that PIC runs with the correct speed. Can tell, that if the speed is not correct and then when you connect it to your PC it will tell you something like "An illegal USB device is....". I have quite fresh experience of that. I have also verified the speed with a oscilloscope to be correct now. And as earlier told, PIC works just fine with the USB commands commented in Pic Basic Rro.

On these chips, if the main oscillator isn't working, it can switch over to the internal oscillator at a different freq.

I'm not quite sure about this, meaning what? If it works without USB (same configuration) shouldn't it the work also with the USB or at least every part should see the right frequency. As earlier said, it works fine without the USB compiled to the code. Ex. if you have a 12MHz crystal, it is first, inside PIC divided with 3 (12/3, 8/2, 4/1, 16/4, 20/5 etc) to get 4MHz that is then multiplied to 96MHZ that goes to USB use and on the other hand divided with 2 to get the 48MHz for the PIC other parts. Then when one instruction takes 4 clock cycles to accomplish, the real speed of a 48MHz PIC is actually 12MHz. That is when you can see the crystal frequency, the reference. So, one basic instruction is about 83 ns long.
Correct?

[arniepj]

In your configuration bits, the USB voltage regulator needs to be enabled.

[keymuu]

In your configuration bits, the USB voltage regulator needs to be enabled.

I tried how it worked with it on, however without success, that seems not change anything, so the fault is somewhere else...
It seems that I had read the data sheet carelessly

Back to the basic, first question:
Is easyHID generally considered as a 100% working "code generator" and should work straight away? A silly question perhaps when just looking at the picbasic code, but there are other files also that aren't "so clear"...

[Darrel Taylor]

As long as you've done everything exactly right, then yes, An EasyHID program will connect to the computer without any hassles.

I tried how it worked with it on, however without success, that seems not change anything, so the fault is somewhere else...

When you have MORE THAN 1 problem at the same time. It's often hard to find them, because simple trial and error no longer works. No matter what you change, it still won't work.

In the case of the VREGEN. IT MUST BE ENABLED!!!

Please try the attached .HEX file. It's for an 18F4550 @12mhz.
I've set all the configs in the program, so allow meProg to use those settings.
Remove the .TXT extension.

All it does is connect the USB.
All other pins are set to input.
MCLR is disabled.

After programming, be sure to cycle the power ON/OFF once.

This should tell us if it's hardware, or software.

[keymuu]

As long as you've done everything exactly right, then yes, An EasyHID program will connect to the computer without any hassles.


When you have MORE THAN 1 problem at the same time. It's often hard to find them, because simple trial and error no longer works. No matter what you change, it still won't work.

In the case of the VREGEN. IT MUST BE ENABLED!!!

Please try the attached .HEX file. It's for an 18F4550 @12mhz.
I've set all the configs in the program, so allow meProg to use those settings.
Remove the .TXT extension.

All it does is connect the USB.
All other pins are set to input.
MCLR is disabled.

After programming, be sure to cycle the power ON/OFF once.

This should tell us if it's hardware, or software.

Thank you it surely did tell us...

The behavior is exactly the same, no difference. The configuration as earlier, with the exception that the USB voltage regulator is enabled as it should be.

If your code was working (that is surely was, of course, no doubt ) then the fault must be a hw matter. Please take a look at an excerpt from the schematic that is attached. That is the schematic from which the prototype pcb has been done. It is Eagle-cad, and it claims (and so it also is) that the board and schematic are consistent, so it is easier to look at it than on the pcb. I can not see an error there, but I'm often quit blind, too often...

[Darrel Taylor]

Yes, that program definitely works.
Dumped in on an 18F4550 before I uploaded it here.

I don't see anything directly in the schematic.
But up in the top left corner, there's some connections labeled P$1. Where do they go? Nowhere I hope.

Which type USB connector are you using? A, B, mini?

[keymuu]

Yes, that program definitely works.
Dumped in on an 18F4550 before I uploaded it here.

I don't see anything directly in the schematic.
But up in the top left corner, there's some connections labeled P$1. Where do they go? Nowhere I hope.

Which type USB connector are you using? A, B, mini?

I'm really glad at this point that my PIC has a "working firmware" in it, very glad indeed. Thank you Darrel
With working I mean that this is a real milestone here and next I shall/must/will find an error on the pcb. If not ... that is not an option.

I will take a big magnifying glass and look throughly what could be wrong with the pcb. The error/fault/"something wrong" have to be there, so it needs a sharp and thorough inspection...

It is a prototype at this stage. This means that there is an USB connector so you can easily use the USB on it, connect it to your PC etc.

The connectors in the left upper corner are there for the final situation, at that point the USB connector will disappear from the pcb and it is moved then behind those connectors.

The USB connector is B type, attached also an excerpt from the Eagle.pcb just to demonstrate the connector type

A USB mini connector wouldn't be good for testing purposes...

[keymuu]

... error on the pcb. If not ... that is not an option.

Still that is not an option. However can not find anything wrong, it seems to be electrically good when measuring all routes around USB, nothing seems to be wrong or even can not suspect any routes.

However, I have one question, what should one see on D+ and D-?
Now those seem to be steady, about 100mV.

Darrel: that software you kindly provided as a hex-file... When not knowing what is inside I'm not sure about what I should see on those two pins (23,24)?
.

[Darrel Taylor]

However, I have one question, what should one see on D+ and D-?
Now those seem to be steady, about 100mV.

That's not good.
They are a differential pair. So when one is high, the other is low.
You should never see both low.

Oh, and according to the PCB layout, the B-type connector is wired to the SN65220 correctly, and the pinout is right. But is was a pretty small portion. Hard to tell where the traces go from there.

[keymuu]

I had a failure in current supply that seemed to affect also the USB life somehow, however can not explain the process, can only say what I hear and what I can see. That is fixed now, but did not fix the main problem here...

Now I can see on D- something happening quit quickly after power-up, then nothing or let us say the same about 100mV staying quit steady. But the plugged and unplugged sound (ding-dong ... dong-ding) does not come.

Darrel: Could you please add a toggle portA.2 (or lata.2) somewhere in your code so that when your program is running I could detect it via that pin (4). That would help to localize, or at least to take me closer to the error source.

I’m kind of lost here, don’t know should that code say ding-dong or not, and don’t know if it is running or is it stuck somewhere.

[Darrel Taylor]

OK, I'll put a blinky on RA2.
Give me some time to modify and test.

In the mean time.

1. Check the voltage on pin 18 Vusb. It should be ~3.3V.

2. D+ uses the internal pull-up to signify FULL speed operation. You should see around 2.8-3.3 volts on pin 24. If not, disconnect the USB cable, and check again.

3. Try plugging another USB device into that USB port on the computer or hub. Make sure the port itself is working.

[keymuu]

That's not good.
They are a differential pair. So when one is high, the other is low.
You should never see both low.

Yes, of course... however they still are both "down" so probably the USB portion of my PIC is broken. How has that happen, can not tell, don't know but that seems to be the case. Have to wait for Monday to get a new PIC.

Oh, and according to the PCB layout, the B-type connector is wired to the SN65220 correctly, and the pinout is right. But is was a pretty small portion. Hard to tell where the traces go from there.

Everything is ok there, that picture was just for showing the connector. As said earlier, if Eagle says that the board and schematic are consistent then there really can't be such errors. Have measured all traces, they go where they should go and they are not broken either and they are not too close each others either.

Could it be possible that the PIC would have been "broken" when bought? I could not think so, but on the other hand Murphy's law says something else...

[keymuu]

OK, I'll put a blinky on RA2.
Give me some time to modify and test.

Thank you

In the mean time.
1. Check the voltage on pin 18 Vusb. It should be ~3.3V.

USB ON MY PIC HAVE TO BE BROKEN!
There (pin 18) is a voltage that is about 10mV without the cable connected and something over 40mV with cable connected, however that value seems to grow slowly, maybe 10mV in 20sec.

2. D+ uses the internal pull-up to signify FULL speed operation. You should see around 2.8-3.3 volts on pin 24. If not, disconnect the USB cable, and check again.

Well, do not see that as could be guessed... it is broken, I can see on pin 24 (D+) something around 100-200mV

3. Try plugging another USB device into that USB port on the computer or hub. Make sure the port itself is working.

Yes, all ports work as they should. I can change devices from one port to an other without any problems etc.

[Darrel Taylor]

Could it be possible that the PIC would have been "broken" when bought? I could not think so, but on the other hand Murphy's law says something else...

Always a possibility.

Attached is a new HEX file.

It blinks PORTA.2 at a 0.5hz rate. 1 sec on, 1 sec off.

I've re-enabled the Oscillator switchover, in case the main isn't working. If it's switching over, the blinks will get REALLY long. (~20 sec)

WDT is on, in case it locks up somewhere.

And MCLR is still disabled.

[keymuu]

Attached is a new HEX file.

Thank you indeed...

It blinks PORTA.2 at a 0.5hz rate. 1 sec on, 1 sec off.

I've re-enabled the Oscillator switchover, in case the main isn't working. If it's switching over, the blinks will get REALLY long. (~20 sec)

WDT is on, in case it locks up somewhere.

It gives just what you said, on PORTA.2 one can see a 50% cycle about 0.5Hz. When I plug the cable there is a very short pause in that cycle and then it continues again. So at this point I was quit surprised when I saw that D+ and D- worked as they should, one was down and the other up. I heard also the plug and unplug signals (ding-dong and dong-ding) and the port did not die, at least when plug and unplugged three four times.
So how was this possible?
My mistake...
If this (with toggling RA2) was working, why was not the previous one working earlier? At this point I'm sure that I did not use the real file because I renamed it to the one that was last compiled and could so (so I taught) straight away (Ctrl-P) compile it with meProg. Now I know that, that file (last compiled) is not necessary the one you think of if you do not come via/from MicroCode Studio. Now I now (can see) that the name of the used file is also in the caption.

Today I used for the first time File/Open in meProg when I realized that this is also possible, I have not had need to that earlier when one could start the programmer from MicroCode Studio. When I now programmed it (straight from meProg) I can see D+ and D- to be opposites and also Vusb to be 3,20V.

I don't see how this could solve the original problem when it suddenly was not hw matter after all. This misleading thing (suspected hardware failure) was solely and alone my fault, my carelessness...

And MCLR is still disabled.

It seems to me that the meProg overwrites all configurations. I have verified that with the MCLR, it is not disabled when it is "burned" into PIC. There might be some conflict with original configuration and implemented ones.
Used configurations are as an attachment.

[mister_e]

While we don't see of any code, may I suggest you to have a look to the following?

http://www.picbasic.co.uk/forum/showthread.php?t=5418

Also, try to remove that U3 for now.


LAST: disable the watchdog Timer in your config fuses.

HTH

[Darrel Taylor]

It seems to me that the meProg overwrites all configurations. I have verified that with the MCLR, it is not disabled when it is "burned" into PIC.

Check the options in meProg.
Is the "Update Configuration From File" option checked?

[keymuu]

Check the options in meProg.
Is the "Update Configuration From File" option checked?

Ok, so there seems to be that option also ... I need to visit an optician
Now when I tried your code with your config, that option checked, the MCLR did not exist as expected and PORTA.2 worked as earlier, however, it turned out that it kills now my USB port. That is strange indeed??? It says ding-dong, dong-ding a few times although that the cable is plugged just ones to PIC. What is this indicating? I have the feeling that those ding-sounds coming from "nowhere" has something to do with the dieing USB port, but what, that something I can't explain.

What in your the configuration could invoke that port-killing behavior when my configuration (USBmystery2.jpg) did not do that with your code? So, as long as I do not have your config I can not see what it might be, what difference could cause this behavior to kill the USB port. On the other hand, you can see my configuration as a jpg, so could you Darrel please try to see if there is something ... something strange, something odd or anything weird or something that one could suspect.... What is the difference between these two configurations?

This is annoying when the error source seems to be buried so deep that one have to dig until the ports of inferno...

[keymuu]

While we don't see of any code, may I suggest you to have a look to the following?
http://www.picbasic.co.uk/forum/showthread.php?t=5418

I'm sure that the USBdemo.zip file contains all that one need to put up a working USB demo environment with PIC18F4550 and for example a XP compunter or laptop.

However, I'm just really unlucky with all this USB stuff. When I copied all PICBasic stuff from your zip-file to C:\PBP and open the USBdemo.pbp in MicroCode Studio and then try to compile it (by invoking PICBASIC PRO 2.50B) I get the following error:
ERROR Line 81:Redefinition of VAR. (USBDemo.pbp)
Shows then the line highlighted with red:
UCFG var byte EXT ' include UCFG register... Yeah Melabs didn't (

Quit normal reaction to this is to try to comment out that line...however with the consequence of a bunch of errors, Error[118] and one Error[113], all in c:\pbp\usbdemo.asm
Error[113]c:\pbp\usbdemo.asm 134: Symbol not previously definded (_FCMEN_OFF_1H) ; This is the only one, 113
Error[118]c:\pbp\usbdemo.asm 128: Overwriting previous address contents (0000) ;First on line 128 then lines 134, 139, 140 and 141...

I took a to look at the usbdemo.asm file but I thought that better not to try to change anything there. Obviously I'm timid ...

What can here be wrong?

Also, try to remove that U3 for now.

U3? The successor of U2??
Sorry, I'm not familiar with all abbreviations and acronyms

disable the watchdog Timer in your config fuses.

I can do it with my config, but not with Darrels and the outcome is at this point known.

[skimask]

However, I'm just really unlucky with all this USB stuff.

I think the problem might be that you're assuming too much...i.e. PBP will do this, PBP will do that, when it might not be PBP's job to do this or that.

UCFG var byte EXT ' include UCFG register... Yeah Melabs didn't (

Yep, that's a good one...

Error[113]c:\pbp\usbdemo.asm 134: Symbol not previously definded (_FCMEN_OFF_1H) ; This is the only one, 113

Another one for Microchip. I think that's the fixed version, or the broke version. Try changing it to FCMEM and see what happens..

Error[118]c:\pbp\usbdemo.asm 128: Overwriting previous address contents (0000) ;First on line 128 then lines 134, 139, 140 and 141...

http://www.picbasic.co.uk/forum/showthread.php?t=543

[mister_e]

When this USBDemo have been written, i was using PBP 2.47 (or something like that). This have been fixed in V2.50. so just comment the offending line and that's it.

And also since this time MPASM version changed, this explain why your have the error on _FCMEN_OFF_1H... it compile fine using MPASM 5.20.. sure i need to upgrade

[keymuu]

When this USBDemo have been written, i was using PBP 2.47 (or something like that). This have been fixed in V2.50. so just comment the offending line and that's it.

And also since this time MPASM version changed, this explain why your have the error on _FCMEN_OFF_1H... it compile fine using MPASM 5.20.. sure i need to upgrade

I have now MPASM 5.20 installed in the same folder where MPASM 5.14 was. Commenting the the offending line 81 will take you to the next step, but does not solve the problem that follows that and one cannot comment those, or no idea to do so. I thought that v.5.20 would solve the usbdemo.asm errors 118 and 113 but it did not.

What can I do?

[skimask]

I thought that v.5.20 would solve the usbdemo.asm errors 118 and 113 but it did not.
What can I do?

Re-Read post #26 & #27

[keymuu]

Re-Read post #26 & #27

So what can I say...

Another one for Microchip. I think that's the fixed version, or the broke version. Try changing it to FCMEM and see what happens..

This is kind of confusing. It is in c:\pbp\usbdemo.asm and as far as I understand it is generated all over again when basic is compiled. Correct? Or have I a misunderstanding somewhere here?

And also since this time MPASM version changed, this explain why your have the error on _FCMEN_OFF_1H... it compile fine using MPASM 5.20.. sure i need to upgrade

I saw those errors (113,118) with both version (5.14 and 5.20) of MPASM, and those errors are in c:\pbp\usbdemo.asm, rebuild at every compile? ... So I'm confused here also... ...upgrade from 5.20 to what?

[skimask]

This is kind of confusing. It is in c:\pbp\usbdemo.asm and as far as I understand it is generated all over again when basic is compiled. Correct? Or have I a misunderstanding somewhere here?

So change it!

I saw those errors (113,118) with both version (5.14 and 5.20) of MPASM, and those errors are in c:\pbp\usbdemo.asm, rebuild at every compile? ... So I'm confused here also... ...upgrade from 5.20 to what?

And did you read the aforementioned thread that was linked in post #26?

[keymuu]

So change it!

Change what? The understanding? Yes I try to do that ....

And did you read the aforementioned thread that was linked in post #26?

Yes, but I can not see anything else than 3b prompting to take a close look at 18F4550.INC that could be the only thing causing something, but what?
I looks ok to me, however I can't grasp the r,w,w and f:
LIST p = 18F4550, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F4550.INC" ; MPASM Header
AND I can not find the above MPASM Header file,
could that be the villain here?

The basic question is still: Why doesn't DT's code compile and easyHID code compiles but kills the USB-port. ?????

[skimask]

Change what? The understanding? Yes I try to do that ....

FCMEN to FCMEM...Could the statement be taken any other way?

The link in post #27....it's all about the CONFIG fuses, something that is a bit more complicated when using the 18F series PICs. Read it, learn it, live it...the sooner the better...

[keymuu]

FCMEN to FCMEM...Could the statement be taken any other way?

Ok, need the optician again...
Maybe I do not understand what you mean, but the FCMEN is in USBDemo.asm that is generated every time when USBDemo.pbp is compiled with MPASM. I can not find FCMEN in any other file, or should I find it somewhere else? So, if you try change anything in the USBDemo.asm, it will not have any effect, in matter of fact it can be deleted, and it will "born" again on the next compile of USBDemo.pbp. Correct?

The link in post #27....it's all about the CONFIG fuses, something that is a bit more complicated when using the 18F series PICs. Read it, learn it, live it...the sooner the better...

The better one knows... that is true
The concern here (the last one ) is how to compile DT's USBDemo.pbp successfully. Can not see in Melanies 3 and 3b anything that could be the reason for the compile errors here. I may be blind or stupid but I do not see the error source for the the compile errors there... The files in DT's USDemo.zip should work straight away, and probably so they do in general, but not here...

[keymuu]

... compile DT's USBDemo.pbp ... The files in DT's USDemo.zip should work ...

Steve (mister_E) and Darrel, I'm sorry that I mixed you two, sorry
It should have been Steve's USBDemo not DT's, one should not hurry too much...

[mister_e]

Open USBDemo.PBP, look at the top of it.

    '
    '   Pic Configuration
    '   =================
    asm
    __CONFIG    _CONFIG1L, _PLLDIV_1_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L  
                            ;              ;                      ; USB clock source comes from the 96 MHz PLL divided by 2
                            ;              ; [OSC1/OSC2 Src: /1][96 MHz PLL Src: /2]
                            ; No prescale (4 MHz oscillator input drives PLL directly)


    __CONFIG    _CONFIG1H, _FOSC_XTPLL_XT_1H & _FCMEN_OFF_1H & _IESO_OFF_1H 
                            ;                  ;               ; Oscillator Switchover mode disabled
                            ;                  ; Fail-Safe Clock Monitor disabled
                            ; XT oscillator, PLL enabled, XT used by USB
    __CONFIG    _CONFIG2L, _PWRT_ON_2L & _BOR_ON_2L  & _BORV_2_2L  & _VREGEN_ON_2L   
    __CONFIG    _CONFIG2H, _WDT_OFF_2H 
    __CONFIG    _CONFIG3H, _MCLRE_ON_3H & _LPT1OSC_OFF_3H & _PBADEN_OFF_3H & _CCP2MX_ON_3H 
    __CONFIG    _CONFIG4L, _STVREN_ON_4L & _LVP_OFF_4L & _ICPRT_OFF_4L  & _XINST_OFF_4L & _DEBUG_OFF_4L 
    endasm

about now?

That would be great if you could tell us wich MPASM version you're using.

All config fuses can be found in the MPASM Suite folder.

The default installation path is C:\Program Files\Microchip\MPASM Suite

First USBDemo was for the 18F4550 if you're using something else, you'll need to change some files... or go at the following
http://www.picbasic.co.uk/forum/show...8&postcount=99

HTH

[keymuu]

Open USBDemo.PBP, look at the top of it.

about now?

It look equal, it is like this:
__CONFIG _CONFIG1H, _FOSC_XTPLL_XT_1H & _FCMEN_OFF_1H & _IESO_OFF_1H
; ; ; Oscillator Switchover mode disabled
; ; Fail-Safe Clock Monitor disabled
; XT oscillator, PLL enabled, XT used by USB
and is exactly eqal....
By the way, why do you suspect your own code?
I have not changed anything within it and that is why I'm confused here...

That would be great if you could tell us wich MPASM version you're using.

Downloaded it yesterday, it is 5.20

All config fuses can be found in the MPASM Suite folder.

The default installation path is C:\Program Files\Microchip\MPASM Suite

First USBDemo was for the 18F4550 if you're using something else, you'll need to change some files... or go at the following
http://www.picbasic.co.uk/forum/show...8&postcount=99
HTH

I'm using 18F4550, so hopefully there is no need to mess up things more in my mind, too many things to think over already...

[mister_e]

By the way, why do you suspect your own code?

well after ~2 years i've posted that one, i would never suspect it

Let's make sure i understand... you have exactly this line

__CONFIG _CONFIG1H, _FOSC_XTPLL_XT_1H & _FCMEN_OFF_1H & _IESO_OFF_1H

MPASM 5.20+ PBP 2.50 and it still throw you some errors?

If so, if you're using MicrocodeStudio, are you sure that you have manually pointed MPASM to c:\program files\microchip\MPASM suite ?

[mister_e]

for error 118, look at this...
http://www.picbasic.co.uk/forum/show...75&postcount=5

[keymuu]

... i would never suspect it

Let's make sure i understand... you have exactly this line

__CONFIG _CONFIG1H, _FOSC_XTPLL_XT_1H & _FCMEN_OFF_1H & _IESO_OFF_1H

MPASM 5.20+ PBP 2.50 and it still throw you some errors?

As I wrote... Yes Sir! And to be exact, PBP 2.50b !! Confusing ??? ...

If so, if you're using MicrocodeStudio, are you sure that you have manually pointed MPASM to c:\program files\microchip\MPASM suite ?

I believe so, please take a look at the attachment.

More confusing...