|
|
View previous topic :: View next topic |
Author |
Message |
TL
Joined: 15 Sep 2003 Posts: 75
|
Porting problem - 16F876A to 18F242 |
Posted: Mon Dec 08, 2003 10:29 am |
|
|
I was using a 16F876A on a previous project and it worked fine but when I started using 18F242 on the same application board, everything stopped working. I've read some old posts in this forum and tried various solutions but my application still doesn't work. I have now stripped everything to a bare minimum and put the 18F242 into the CCS software prototyping board but still the following program does not flash the LED. I've tried 2 different 18F242 but to no avail. However, the 16F876A works in the CCS board. Here is my code:
Code: |
#include <18F242.h>
#device *=16
#fuses EC_IO,NOPROTECT,NOBROWNOUT,NOWDT,BORV42,NOPUT,NOSTVREN,NODEBUG,NOLVP,NOWRTD,NOWRTB
#use delay(clock=20000000)
#use fast_io(b)
main()
{
set_tris_b(0x00);
while(1)
{
output_high(PIN_B1);
delay_ms(1000);
output_low(PIN_B1);
delay_ms(1000);
}
}
|
As you can see, the external crystal is 20MHz which is declared as RC_IO but still doesn't work. I've also tried HS and EC and again didn't work.
Can someone please give me some pointers? |
|
|
TL
Joined: 15 Sep 2003 Posts: 75
|
Porting problem |
Posted: Mon Dec 08, 2003 10:34 am |
|
|
I use PCWH V3.158. Thanks. |
|
|
Ttelmah Guest
|
Re: Porting problem - 16F876A to 18F242 |
Posted: Mon Dec 08, 2003 11:42 am |
|
|
TL wrote: | I was using a 16F876A on a previous project and it worked fine but when I started using 18F242 on the same application board, everything stopped working. I've read some old posts in this forum and tried various solutions but my application still doesn't work. I have now stripped everything to a bare minimum and put the 18F242 into the CCS software prototyping board but still the following program does not flash the LED. I've tried 2 different 18F242 but to no avail. However, the 16F876A works in the CCS board. Here is my code:
Code: |
#include <18F242.h>
#device *=16
#fuses EC_IO,NOPROTECT,NOBROWNOUT,NOWDT,BORV42,NOPUT,NOSTVREN,NODEBUG,NOLVP,NOWRTD,NOWRTB
#use delay(clock=20000000)
#use fast_io(b)
main()
{
set_tris_b(0x00);
while(1)
{
output_high(PIN_B1);
delay_ms(1000);
output_low(PIN_B1);
delay_ms(1000);
}
}
|
As you can see, the external crystal is 20MHz which is declared as RC_IO but still doesn't work. I've also tried HS and EC and again didn't work.
Can someone please give me some pointers? |
An external crystal, will not work on EC_IO. This will only work with an external oscillator (the OSC2 output pin needed to drive the crystal, is turned into an IO pin by this setting). HS, is the correct setting.
The oscillator on the 242, is more critical of crystal types, than those on the older chips. This is because of the inclusion of the PLL to allow *4 operation, and can sometimes lead to problems. Using a lower gain crystal, or a series resistor with the crystal can be necessary for reliable operation (though the failure without these is normally operating at the wrong frequency, not a complete failure. HS is the correct setting for an external 20MHz crystal, but on some high gain crystals, XT (designed for lower frequency use), works better.
Are you sure your supply is 100% stable?. The brownout detector, is sensitive to quite small glitches, and I have seen a number of chips fail to work because this is tripping. The '4.2v' setting, has a trip point between 4.2, and 4.45v.
Try with a fuse statement, something like:
HS, NOWDT, PUT, BROWNOUT, BORV27, NOLVP, STVREN, NODEBUG, NOOSCSEN, WRT
*=16, is redundant on the 18 family.
Double check you have supply connections to both ground pins. The 18 family, are more critical of faults here than the 16 family.
Best Wishes |
|
|
TL
Joined: 15 Sep 2003 Posts: 75
|
Solution |
Posted: Tue Dec 09, 2003 3:58 am |
|
|
Thanks for your useful comments Ttelmah. After more investigation, the problem was caused by the old firmware V1.03 in the ICD-S. Although the downloading appeared to be fine, actually it wasn't right!!! When I downloaded the same hex file to the 18F242 using a WARP13A, the above program worked I then upgraded the ICD-S firmware to V1.15 and downloaded the hex file using the ICD-S and again the program worked.
The reason I re-programmed it to V1.03 was because I had a RAM error message previously after downloading with V1.14 and V1.15 (see my previous post "ICD-S downloading problem with 18F242"). For some unknown reason, with V1.15 re-programmed, I cannot repeat this error message using the ICD-s on the CCS software prototyping and my application boards. Anyway, as long as it doesn't come back then it is fine! However, I still suspect there may be bugs in V1.15. I've already reported this problem to CCS regarding my previous post "ICD-S downloading problem with 18F242" but I still haven't received a reply from them yet. |
|
|
|
|
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
|