View previous topic :: View next topic |
Author |
Message |
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
Strange 16F690 INTRC fuse and port A.5 problem. |
Posted: Wed Aug 15, 2007 8:16 am |
|
|
This is a wierd one.
On a 16F690 with ver 4.049 compiler.
If i use the fuse INTRC_IO which should free both of the osc pins A.4 and A.5 for use as IO then i am unable to use A.5 as a output, it appears to be just floating as if it's still an input. (trisa is set correctly).
But, if i use the fuse INTRC which should (and does) have A.4 as clk out and leave A.5 as general IO then A.5 works correctly as an output.
That is the only change between A.5 working and not working, just the fuse.
So i compared the full .lst files and there are no differences between the 2 versions except the fuse, the rest of the code compiles identically.
Compiler version 4.045 is the same. 3.049 can't handle a 16F690
I tried version 4.050 but that just locks up (on the device) when you press a key so i guess CCS have broken something again.
Any thoughts ?
Thanks,
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Wed Aug 15, 2007 8:39 am |
|
|
I'm using the ICD-U40 programmer from within PCWH
Jim |
|
|
Ttelmah Guest
|
|
Posted: Wed Aug 15, 2007 8:50 am |
|
|
3.049, may not be able to handle the 690, but 3._2_49, does. However the wizard gets very screwed, so manual setup is needed.
Have you looked at what fuse is actually generated (inside the programmer, but not inside CCS). 3.249 & 4.042, both seem to generate the correct fuse output.
Best Wishes |
|
|
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Wed Aug 15, 2007 8:57 am |
|
|
Hi,
Sorry, of course i meant 3.249.
I tried to compile the existing code in 3.249 and it came up with a handful of compile errors including not recognising port_b_pullups().
I may try to get it to compile with 3.249 later.
The fuse values generate by the compiler are correct.
Thanks,
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Wed Aug 15, 2007 9:14 am |
|
|
I commented out the functions that v 3.249 was complaining about as they weren't related to Port a and i have the same problem with 3.249
Very strange.
Why does changing the fuse effect Port a.5 , thats the wierd thing.
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Wed Aug 15, 2007 9:30 am |
|
|
Ive just done a File compare of the 2 hex files with the only difference being the fuse intrc (port a.5 works) or intrc_io (port a.5 doesn't work).
This is the result:
Code: | Comparing files intrc.hex and INTRC_IO.HEX
***** intrc.hex
:060A70006400D72A6300B8
:02400E008D33F0
:00000001FF
***** INTRC_IO.HEX
:060A70006400D72A6300B8
:02400E008C33F1
:00000001FF
*****
|
As far as i can tell this means ohly the fuse is different.
Does this make any sense to anybody ?
Am i looking at a pic bug ? There is no Erratta for the 16F690
Jim |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed Aug 15, 2007 10:37 am |
|
|
I compiled the test program shown below with vs. 4.049 and it worked.
Pin A5 toggles up and down.
MPLAB reports the following silicon revision level for the PIC:
Quote: |
Target Device PIC16F690 found, revision = Rev 0x5
|
Code: |
#include <16F690.h>
#fuses INTRC_IO, NOWDT, NOPROTECT, BROWNOUT, PUT, NOMCLR
#use delay(clock=8000000)
//===============================
void main()
{
while(1)
{
output_high(PIN_A5);
delay_ms(500);
output_low(PIN_A5);
delay_ms(500);
}
} |
|
|
|
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Wed Aug 15, 2007 10:38 am |
|
|
Doh ! time.
I just found i'd used setup_timer_1() in my code in a place where i'd intended to use set_timer1().
The value i was sending in error to setup_timer_1() seems to have turned on the timer 1 external osc option which uses A.4 and A.5 and overrides trisa on those port pins (so no output).
But, if you use the Fuse INTRC i guess the pic knows it can't use the timer 1 external osc (as A.4 is clkout) and so leaves a.5 as general IO.
At least it makes sense now, thanks (and sorry) to anybody who spent time thinking about the problem.
Jim |
|
|
Jim Hearne
Joined: 22 Dec 2003 Posts: 109 Location: West Sussex, UK
|
|
Posted: Wed Aug 15, 2007 10:40 am |
|
|
Thanks for the time you spent on that PCM, as you can see from my message above it was a combination of a typing mistake and the way the pic worked.
I found it when i gradually cut the program down to the bare minimum.
Thanks again,
Jim |
|
|
|