Continue to Site

PIC with 32kHz external clock not running

Status
Not open for further replies.

Franchie

New Member
Hello,

I am using the 32kHz output of the MAXIM DS3234 Real-time clock as an external clock input for my PIC16F877A (in place of any oscillator crystal). As I understand the datasheet, the connection should be very simple, and the 32kHz signal should be connected to OSC1/CLKIN of the PIC directly. Similarly, the configuration bits have to be set to one of HS, XT or LP (LP is probably best in this case because of the low frequency, but HS should be great for debugging).

The problem is that it does not work: when programmed, nothing is executed. When in an ICD2 debug session, the session cannot be opened (Error ICD0083). However, everything works when a 20MHz clock is connected externally in the place of the 32kHz. Thus the problem is probably linked to the 32kHz signal.

Upon analysis, the signal appears good enough: there is little noise, its amplitude reaches 0.97 Vcc, and has a duty-cycle of roughly 30-40%. It fluctuates slightly when the ICD2CLK line is active, probably due to the routing, but this should be of little concern.

So if you have any ideas of what I might be doing wrong, please throw suggestions at me! Your help is greatly appreciated!
Franchie.

Attachments

• Weather_sch.pdf
204.9 KB · Views: 239
Last edited:

ericgibbs

Well-Known Member
hi,
Does the 32KHz output of the RTC require a pullup resistor.?

Franchie

New Member
Hi, thanks for the response!
I don't believe that a pullup resistor is needed in this case, because the RTC has a "push-pull" output, and also because the waveform reaches the desired amplitudes... I have tried with a pullup resistor anyway, but this had little effect :S.

ericgibbs

Well-Known Member
Hi, thanks for the response!
I don't believe that a pullup resistor is needed in this case, because the RTC has a "push-pull" output, and also because the waveform reaches the desired amplitudes... I have tried with a pullup resistor anyway, but this had little effect :S.

hi,
Looking thru the DS3234 I see that you are correct, I use the DS1307 which does require a pullup.

Are you using a scope to measure the 32KHz on the OSC1 pin.?

EDIT:
Is there any clock signal on OSC2 output.?
The other common problem, are the same delay routine times being used for the 32KHz as the 20MHz.??

Last edited:

Franchie

New Member
I am indeed using a scope on the OSC1 pin, getting a pretty clean signal at around 32kHZ as expected (its an old oscilloscope, so its not possible to tell exactly).

b) No code is yet able to run, so that is not yet an issue...
a) Interesting point! I would have imagined that the output of OSC2 would have been a mirror of OSC1/CLKIN. However, it stays basically at Gnd, with regular 'capacitor charging curves', as if the clock signal was trying to charge a capacitor. It never reaches more than about 1/5 Vcc though... Is this the expected behaviour, or am I missing something?

Last edited:

Mr RB

Well-Known Member
Maybe you have a software bug. If something is timing out etc at the lower clock speed and the software appears to be not executing. Could you connect a 32kHz typical xtal and see if it runs then? That would be a quick test.

The output at OSC2 may not echo the signal at OSC1 if you are in HS mode?

Franchie

New Member
My software code is at its most basic level for the moment, it sets a port to output mode, and sets its value to 0xFF. Should be a valid test, I believe. So I believe that the error lies either in the clock signal (which looks valid) or the config bits. This would explain why programming works fine, but debug and execution fail. My current code is below for peer review, it is just a basic test code that does nothing useful yet.

Also Mr RB, thanks for the suggestion, being a poor under-equipped student, I don't have a crystal handy, but will try with a signal generator when I get access to one next week, it looks like a good idea...

So here's the code:
Code:
	list p=16f877a
include "P16F877A.inc"

__config _HS_OSC & _WDT_OFF & _LVP_OFF & _PWRTE_OFF & _CP_OFF & _WRT_OFF & _CPD_OFF & _BODEN_OFF

; MACRO
MOVLF   macro  literal,dest
movlw  literal
movwf  dest
endm

; START
org  0x0000             ;Reset vector
nop
goto  main

main
banksel		PORTD
MOVLF		0,		TRISD
MOVLF		0xFF,	PORTD
goto $end Thanks again so much for all your help! Franchie. birdman0_o Active Member Your code is wrong ; MACRO Code: MOVLF macro literal,dest [COLOR="Red"] movf literal,w[/COLOR] movwf dest endm You were writing the LSB of that RAM address Franchie New Member Are you sure? MOVLF as used in the code moves a litteral into a register. Therefore the steps to carry this out are (since it is not possible to do it in one step): 1) Place the litteral into a working register w, via movlw. 2) Move w to a register, via movwf In my opinion, using movf would only be valid if 'litteral' was a register, which it isn't. It would make 'litteral' not an immediate number, like it is used, but an address of a register. Surely this is incorrect, no? Unless the rules are somehow changed inside a "macro" construct (I had believed this to be a simple compile-time substitution of 'litteral' and 'dest'). Thanks for all your help, this all really helps narrow down the problem! birdman0_o Active Member Oh nvm. You are right, what you didn't do is switch back to bank0 (For PortD) ! birdman0_o Active Member Code:  list p=16f877a include "P16F877A.inc" __config _HS_OSC & _WDT_OFF & _LVP_OFF & _PWRTE_OFF & _CP_OFF & _WRT_OFF & _CPD_OFF & _BODEN_OFF ; MACRO MOVLF macro literal,dest movlw literal movwf dest endm ; START org 0x0000 ;Reset vector nop goto main main banksel [COLOR="Red"]TRISD[/COLOR] MOVLF 0, TRISD [COLOR="Red"] banksel PORTD[/COLOR] MOVLF 0xFF, PORTD goto$
end

Mr RB

Well-Known Member
Wouldn't that have generated a warning at assemble time??

birdman0_o

Active Member
A warning yes, but it would still compile! He probably just ignored it and was happy with the green 100%.

Franchie

New Member
Hello!

You are indeed all correct, I forgot to switch to bank 1. Since switching to bank 1 does not get rid of the warning (under my mplab anyway, maybe you have some idea how to avoid this?), I got used to ignoring those warnings, and since it was a test program I did not pay attention to it. birdman0_o is correct, the green bar is far too tempting .

But more humiliatingly, execute now works, which means my oscillator was probably fine all along, sorry for having made such an elementary mistake! :S

Strangely, debug mode still does not work, which is the reason why I jumped to the unfounded conclusion that it had to be a problem with the oscillator. I am not too bothered by this, since I can now use a normal usart for debugging, but out of curiosity, why would the debugger not be able to connect to the debug executive? I have switched to "debug" mode during compilation, flash it as usual, and it won't connect, are there any extra wires that need to be connected? Maybe the PIC16F877A simply does not support debugging?

Thank you all in any case, and I'm very sorry about it having been such a stupid elementary mistake :S.

Pommie

Well-Known Member
The debugger works at the same speed as the chip and 32k is veeerrrry slow.

Mike.

Franchie

New Member
Okay, so its basically so slow that it timed-out on connection? Makes sense then that it worked with a 20MHz clock...
Alright then, thank you all so much for all the help you have given me!

Status
Not open for further replies.

Replies
0
Views
386
Replies
3
Views
3K
Replies
4
Views
5K
Replies
1
Views
864
Replies
10
Views
1K