![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
aleruggeri87
Joined: 26 Mar 2015 Posts: 3
|
PIC18F67J94 power on problem |
Posted: Thu Mar 26, 2015 3:37 pm |
|
|
Hi all,
we are experiencing some problems at the power-up with the PIC in object.
Basically we want to use this PIC with the USB CDC.
We are using the internal clock and an external power-on-reset chip.
After many tests, we wrote this very simple program:
Code: |
#include <18F67J94.h>
#fuses FRC_PLL, PLL1, NOPROTECT, DEBUG, NOBROWNOUT, NODS
#use delay(clock=64MHz,internal=4MHz)
void main(void){
while(true){
output_bit(dummy,0);
delay_us(400);
output_bit(dummy,1);
delay_us(400);
}
}
|
and we can see the pin toggle.... Every time we turn on the power supply.
However, when we modify the delay instruction to add the USB support:
Code: |
#use delay(clock=64MHz,internal=4MHz, USB_FULL, act=USB)
|
in this case at the power-up sometime the pin toggle, but often it doesn't!
In this stall condition, we try to reset the PIC, through the MCLR pin and after several attempts the pin finally starts to toggle.
We try also to enable the watchdog, hoping to auto implement this reset procedure, but without any results.
We are using the v.5.024 and we also try with the latest demo (5.043), without any improvements.
Any suggestions?
Thanks and regards
Alessandro. |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9174 Location: Greensville,Ontario
|
|
Posted: Thu Mar 26, 2015 3:57 pm |
|
|
I don't use that PIC but have a question...
"output_bit(dummy,0); "
Where did you declare or assign a value to 'dummy' ?
also...
I see
#fuses ... debug
This could cause problems. I know the 'debug' code is different than the 'release' version..
then...
there's the clock option.
Is that PIC capable of using USB with the internal 4MHz rc oscillator? Many can't run 'solid' (48MHz for USB ?)
Just some things to ponder...
Jay |
|
![](templates/subSilver/images/spacer.gif) |
aleruggeri87
Joined: 26 Mar 2015 Posts: 3
|
|
Posted: Thu Mar 26, 2015 4:19 pm |
|
|
Hi Jay,
yes, I forgot to copy
Code: |
#define dummy PIN_F6
|
Very good hint the DEBUG directive, but... I've tried without and nothing, the same as before.
Regarding the clock option, I've read that using the act=USB directive the PIC automatically resynchronize the internal clock with the USB clock.
Thanks for the suggestions!
Alessandro. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Mar 26, 2015 4:55 pm |
|
|
I compiled your program with the two different #use delay() statements
and then compared the .LST files. The only difference is the USB version
has this code added to the PIC's startup code:
Code: |
0004A: BCF ACTCON.ACTEN
0004C: MOVLW 90
0004E: MOVWF ACTCON
|
According to the 18F67J94 data sheet, setting ACTCON to 0x90 will set
the ACTSRC bit for USB tuning:
Quote: |
3.13.3.2 Active Clock Tuning Source Selection
The ACT reference clock is selected with the ACTSRC
bit of the ACTCON register. The reference clock
sources are provided by the:
• USB module in full-speed operation (ACT_clk)
• Secondary clock at 32.768 kHz (SOSC_clk)
|
So, it's possible that you need to wait for the internal oscillator to lock.
Try adding the lines shown in bold below:
Quote: |
#bit ACTLOCK = getenv("BIT:ACTLOCK")
void main(void)
{
while(!ACTLOCK); // Wait for internal oscillator to lock
while(true){
output_bit(dummy,0);
delay_us(400);
output_bit(dummy,1);
delay_us(400);
}
}
|
This is just for testing, because there's no timeout if it stays in the while()
loop forever. |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19369
|
|
Posted: Fri Mar 27, 2015 2:46 am |
|
|
I've seen this problem.
It happens if you enable the USB sync, and the USB bus is floating. The chip sometimes sees noise, and tries to sync to this, and then won't reliably wake....
Part of the problem is that the pull up resistor on the USB bus is not enabled, when you start the chip, so the lines are undriven.....
I found the reliable way to deal with this was to not enable the ACT on boot, but instead wait till the USB was connected. Then use the setup_act function to turn it on:
Code: |
if (usb_attached())
setup_act(ACT_ENABLED|ACT_TUNED_TO_USB);
else
setup_act(ACT_DISABLED);
|
Obviously you need the hardware connection sense for this to work. |
|
![](templates/subSilver/images/spacer.gif) |
aleruggeri87
Joined: 26 Mar 2015 Posts: 3
|
|
Posted: Fri Mar 27, 2015 2:53 am |
|
|
I tried to disassemble the code and I've obtained the same results.
But I also understand that the problem is not the Active Clock Tuning, but the USB itself. In fact I've tried to use this setting:
Code: | #use delay(clock=64MHz,internal=4MHz, USB_FULL) |
Also this code hiccups.
The disassembled code is identical to the one without USB_FULL, but the fuses are not. The 4°fuse (PLLDIV) changes form FE (8x multiplier) to F1 (96MHZ pll, OSC div by 2 - 8MHz input).
Modifying the delay statements with internal=8MHz... no improvements.
I also monitored the clock output pin and it look like good, after a brief startup transient, it lock correctly every time.
Any others hints?
Thanks
Alessandro. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|