PDA

View Full Version : easyHID question



keymuu
- 22nd October 2008, 00:56
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... :rolleyes:

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
- 22nd October 2008, 01:19
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
- 22nd October 2008, 01:36
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...:confused: There is also a SN65220DVB circuit swallowing bigger voltages, for real transient high voltage protection.
Why use condoms if you are sure? :D

Darrel Taylor
- 22nd October 2008, 01:53
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.
<br>

keymuu
- 22nd October 2008, 02:25
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.
<br>

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 ... :p

Darrel Taylor
- 22nd October 2008, 02:54
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. :o

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
- 23rd October 2008, 14:26
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.:mad:


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

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
- 23rd October 2008, 17:47
In your configuration bits, the USB voltage regulator needs to be enabled.

keymuu
- 23rd October 2008, 21:18
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 :o

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"...:confused:

Darrel Taylor
- 24th October 2008, 00:08
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
- 24th October 2008, 05:11
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... :o

Darrel Taylor
- 24th October 2008, 05:54
Yes, that program definitely works.
Dumped in on an 18F4550 (http://www.picbasic.co.uk/forum/album.php?albumid=1&pictureid=5) 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
- 24th October 2008, 12:47
Yes, that program definitely works.
Dumped in on an 18F4550 (http://www.picbasic.co.uk/forum/album.php?albumid=1&pictureid=5) 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...:cool:

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 :D

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

keymuu
- 25th October 2008, 15:31
... 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
- 26th October 2008, 02:09
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
- 26th October 2008, 02:27
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...:mad:

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. :o

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
- 26th October 2008, 02:51
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
- 26th October 2008, 03:13
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:o... 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...:rolleyes:

keymuu
- 26th October 2008, 03:42
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
- 26th October 2008, 03:49
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...:rolleyes:
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.
<br>

keymuu
- 26th October 2008, 22:02
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... :o
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...:o


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
- 27th October 2008, 21:05
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
- 27th October 2008, 22:15
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?

<img src="http://www.picbasic.co.uk/forum/attachment.php?attachmentid=2935" /><!-- 2935 -->

keymuu
- 28th October 2008, 16:26
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 :D
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...:eek:

keymuu
- 28th October 2008, 17:54
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 :o(

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 :o


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
- 28th October 2008, 17:58
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 :o(
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
- 28th October 2008, 18:16
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
- 28th October 2008, 21:15
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. :confused:

What can I do?

skimask
- 28th October 2008, 21:34
I thought that v.5.20 would solve the usbdemo.asm errors 118 and 113 but it did not. :confused:
What can I do?
Re-Read post #26 & #27

keymuu
- 28th October 2008, 22:51
Re-Read post #26 & #27

So what can I say...:confused:


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...:confused: ...upgrade from 5.20 to what?

skimask
- 28th October 2008, 23:39
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...:confused: ...upgrade from 5.20 to what?
And did you read the aforementioned thread that was linked in post #26?

keymuu
- 29th October 2008, 00:57
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? :cool:

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

skimask
- 29th October 2008, 04:46
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
- 29th October 2008, 08:02
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
- 29th October 2008, 17:40
... 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...:rolleyes:

mister_e
- 29th October 2008, 17:56
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/showpost.php?p=38468&postcount=99

HTH

keymuu
- 29th October 2008, 18:51
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/showpost.php?p=38468&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...:o

mister_e
- 29th October 2008, 18:57
By the way, why do you suspect your own code?
:D well after ~2 years i've posted that one, i would never suspect it :D

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
- 29th October 2008, 19:24
for error 118, look at this...
http://www.picbasic.co.uk/forum/showpost.php?p=6775&postcount=5

keymuu
- 29th October 2008, 19:39
... i would never suspect it :D

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... :confused:

mister_e
- 29th October 2008, 19:42
Holly crap... anyways, try to remove ALL MPLAB version, then re-install the latest version of it.

Assuming your PBP 2.50b is in the usual c:\pbp folder and MicroCode point to it... I'm out of ressources....

skimask
- 29th October 2008, 20:03
Assuming your PBP 2.50b is in the usual c:\pbp folder and MicroCode point to it... I'm out of ressources....

Maybe the original CD from MeLabs was corrupted! :D

keymuu
- 29th October 2008, 21:37
for error 118, look at this...
http://www.picbasic.co.uk/forum/showpost.php?p=6775&postcount=5
That link suggest that one should comment those lines that produce the "overwriting previous address content" the 118 error from corresponding .INC file, that is in this case C:\PBP\18F4550.INC.
I can find only one line (line 20) that is equal in that file:

__CONFIG _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L

The strange thing here is, that when compiling USBDemo.pbp again it blames again also on the same commented line in USBDemo.asm !! :eek:
I would have expected that line to disappear from the the generated 118-error list...
Is it somewhere else also :confused:
I have tried to look for it but can only find one in C:\Program Files\Microchip\MPASM Suite, but the content is quit different looking there.

mister_e
- 29th October 2008, 21:49
comment ALL CONFIG lines in your c:\pbp\xyz.INC file



;************************************************* ***************
NOLIST
ifdef PM_USED
LIST
"Error: PM does not support this device. Use MPASM."
NOLIST
else
LIST
LIST p = 18F4550, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F4550.INC" ; MPASM Header
;__CONFIG _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L
;__CONFIG _CONFIG1H, _FOSC_HSPLL_HS_1H
;__CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
;__CONFIG _CONFIG3H, _PBADEN_OFF_3H
;__CONFIG _CONFIG4L, _LVP_OFF_4L & _ICPRT_OFF_4L & _XINST_OFF_4L
NOLIST
endif
LIST
EEPROM_START EQU 0F00000h
BLOCK_SIZE EQU 32

skimask
- 29th October 2008, 23:14
Unless I'm mistaken...and I don't think I am...isn't that what I suggested back in Post #26?
I think it is...I really do. I suggested that the O/P read the thread, the whole thread, and nothing but the thread. Either the O/P didn't get it, or the O/P didn't read it, because it's pretty much spelled out in black&white what to do, what not to do, and why what is happening actually happens and where to find the files...

keymuu
- 30th October 2008, 00:07
comment ALL CONFIG lines in your c:\pbp\xyz.INC file



;************************************************* ***************
NOLIST
ifdef PM_USED
LIST
"Error: PM does not support this device. Use MPASM."
NOLIST
else
LIST
LIST p = 18F4550, r = dec, w = -311, w = -230, f = inhx32
INCLUDE "P18F4550.INC" ; MPASM Header
;__CONFIG _CONFIG1L, _PLLDIV_5_1L & _CPUDIV_OSC1_PLL2_1L & _USBDIV_2_1L
;__CONFIG _CONFIG1H, _FOSC_HSPLL_HS_1H
;__CONFIG _CONFIG2H, _WDT_ON_2H & _WDTPS_512_2H
;__CONFIG _CONFIG3H, _PBADEN_OFF_3H
;__CONFIG _CONFIG4L, _LVP_OFF_4L & _ICPRT_OFF_4L & _XINST_OFF_4L
NOLIST
endif
LIST
EEPROM_START EQU 0F00000h
BLOCK_SIZE EQU 32

This is weird, totally crazy :confused:

When I comment those lines, I can see that they are commented, but when I compile USBDemo.pbp it produces the same errors (118) and when I then take a look at that 18F4550.INC file again, the comment marks are gone :eek:

Then I thought that I shall make a small experiment. From file properties I changed it to read-only and the tried to compile USBDemo.pbp... The first thing that happens is "save as" 18F4550. Ok, now I now that PBP does write it over again and again. Next I unchecked the read-only feature and compiled USBDemo.pbp, et voila, for the very first time it compiled without errors :)

What did happen? Why do we have to go via read-only ???? to solve such a persistent problem... incredible... Can you explain this? Can you??? If you can , please do... Thank you :-)

I burned it to PIC and did not yet test anything else than plug and unplug it for several times and I'm really glad that the USB port is still alive, that is for the very first time in my USB history... well, DT's hex with my config was also working, but that is another story...

I will try the communication to my PC tomorrow.... Not too much sweet at once...

I'm glad at this point, very glad... Thank you Steve!

PS. What if such errors (118) pops up again at some stage? It's kind of difficult to believe that the aid is "go via read-only"?... ???

mister_e
- 30th October 2008, 01:39
I don't know why it happened to you... usually you just comment those line, you save the "INC file .... ET VOILA!

Not much
Rien d'autre à changer
Compile and run
Away you go
Yada yada.

USBDeview is a nice tool to uninstal/remove/monitor your HID devices... handy and free
http://www.nirsoft.net/utils/usb_devices_view.html

keymuu
- 31st October 2008, 02:12
I don't know why it happened to you... usually you just comment those line, you save the "INC file .... ET VOILA!

Not much
Rien d'autre à changer
Compile and run
Away you go
Yada yada.

USBDeview is a nice tool to uninstal/remove/monitor your HID devices... handy and free
http://www.nirsoft.net/utils/usb_devices_view.html
I forgot to say that I found that the B-type USB connector shield was not properly connected to GND. When I noticed that I did connect it as it should be connected. It is kind of funny that the connector, it self is not connected and this leads to that the shield is "floating"?:mad:

I have a feeling that fixing that shield connection to GND helped to solve other parts of the USB connection problem. It did of course not have any effect to the compile problems...

I could have tried to delete the file 18F4550.INC before that "read-only" phenomena, but unfortunately I did not try it.
Now of course I can not do that! Maybe good so, but the mystery thing remains, who wrote (or copied from...) it over as long as I got the the error 118 over and over again....:confused:

For now:
Darriel, Steve, skimask ... THANK YOU
Thank you very much indeed, thank you all who helped with this many-faceted and persistent problem,...:)

mister_e
- 31st October 2008, 18:36
Whatever your problem is/was, the most important thing is to solve it, and understand why :D