Always a possibility.Originally Posted by keymuu
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...
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.
Last edited by Darrel Taylor; - 26th October 2008 at 04:17. Reason: 20 sec
DT
Thank you indeed...
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.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.
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...
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.And MCLR is still disabled.
Used configurations are as an attachment.
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
Last edited by mister_e; - 27th October 2008 at 21:13.
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
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?
U3? The successor of U2??Also, try to remove that U3 for now.
Sorry, I'm not familiar with all abbreviations and acronyms
I can do it with my config, but not with Darrels and the outcome is at this point known.disable the watchdog Timer in your config fuses.
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.
Yep, that's a good one...UCFG var byte EXT ' include UCFG register... Yeah Melabs didn't
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[113]c:\pbp\usbdemo.asm 134: Symbol not previously definded (_FCMEN_OFF_1H) ; This is the only one, 113
http://www.picbasic.co.uk/forum/showthread.php?t=543Error[118]c:\pbp\usbdemo.asm 128: Overwriting previous address contents (0000) ;First on line 128 then lines 134, 139, 140 and 141...
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
Steve
It's not a bug, it's a random feature.
There's no problem, only learning opportunities.
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.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
What can I do?
Check the options in meProg.
Is the "Update Configuration From File" option checked?
DT
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 expectedand 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...
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks