easyHID question

[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]

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

[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

[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.

[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]

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]

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.