Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

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: 283
Last edited:
hi,:)
Does the 32KHz output of the RTC require a pullup resistor.?
 
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.
Thanks for your help!
 
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.
Thanks for your help!

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:
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).
Thanks for your help!

EDIT: Concerning your added questions:
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?
Thanks again for your help!
 
Last edited:
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?
 
Thanks for your responses!
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.
 
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!
 
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
 
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 :p.

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.
 
The debugger works at the same speed as the chip and 32k is veeerrrry slow.

Mike.
 
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.

Latest threads

New Articles From Microcontroller Tips

Back
Top