PIC16f870,24C65,and RTC72421 in Assembler lockup

Thread Starter

Retiredguy

Joined Feb 24, 2007
28
Well, after a month of trying to get this thing to work, I need help. Basically, what I am trying to do is build a clock which will record the date and time when tripped by some sort of device. The program is built, however I am having a problem in one part of the program where I try to read the 24C65. The program is directed by a couple of switches in the circuit and I can read and write to the RTC with no problem, It displays just fine and will keep good time for weeks at a time, and I believe that the portion of the program where I write to the 24C65, is working, but I cannot read it. When I set the switches to read the 24c65 and drop into that part of the program, I cannot get out of it and my display will blank out or move what I have all ready written to it. I have stepped thru the program dozens of times and it seems to work in MPLAB IDE but in the real world, well, it is a different matter.

Attached is my code and also a PDF of the schematic. Any help to point me in the right direction would be greatly appreciated.


Mike
 

Attachments

Papabravo

Joined Feb 24, 2006
21,159
It sounds like you have dropped into a section of code that is looping on a condition that can never be satisfied. It is incredibly easy to write such things and incredibly hard to resolve them because a simulator does not behave the way real hardware behaves.
 

Thread Starter

Retiredguy

Joined Feb 24, 2007
28
John,
The problem starts when I drop into the label "MEMREAD" in my code above. I placed a couple of commands to light up a LED and turn it off as it goes thru that portion of the code but no matter what position I place the switches I cannot get the LED to turn off. I know that it is stuck in some loop there but cannot figure where I went wrong in the program.
I have attached the code in text format
 

Attachments

Papabravo

Joined Feb 24, 2006
21,159
I can't tell much from looking at the code except you are trying to do I2C by manipulating the port pins. The code is incredibly difficult to follow and understand but I see numerous opportunities to loop on single conditions, particularly the switches. I expect those switches are not de-bounced in hardware, and the code looks fast enough to get locked in a place where you don't expect. You have some external routines that your program is linked with that may or may not contribute to the problem. I just can't tell.
What is the statement that turns on the LED?
Is it this one? --> BSF PORTB,RB7 ;TURN ON RED LED
What is the statement that turns it off?
Is it this one? --> BCF PORTB,RB7 ;TURN OFF LED

After you turn on the RED LED you initialize the variable count1. What is the value in count left over from the previous code? It should be zero, but can you verify that?

Your tests for EQUAL to 3 and 8 using the XOR operation ignore what happens if the value is ever greater than 8. The program could run for a long time as it loops through all possible values to get back to 8. If you use a subtract operation you can still use the zero flag, but the carry will tell you if there is an error or not.
 
Last edited:

Thread Starter

Retiredguy

Joined Feb 24, 2007
28
Papa,
As far as the LED commands goes, you are correct, that is the code that manipulate the LED. I also thought that switch bounce was a problem and did debounce SW1, the one connected to RB2 and it had no effect on the results I was getting. The switches all work in the other portions of the program without any problem . I am only running this thing at about 104K Hz which means that the instructions are running at 26K Hz. As far as the external programs go, other than the "delay10" routine, none have any variables in them and all they do is manipulate the pins of the RTC and LCD display for the read and write functions of those devices. And yes, the variable "count1" should be cleared before I clear it again( was place there in the hope that that might help with my problem). How this is supposed to work is that I first give the start command to the 24C "MEMSTART". Next I write the control byte to the 24C ( using the value A0 hex in PORTC and thru the subroutine "ROTATELEFT") this should inform the 24C to read : ( the MSB should go in first according to the data sheet). Next I write the address to the 24c where I wish to start reading the data with the variables "memadd1 & memadd0" which both should be zero with the subroutine "ROTATELEFT". Finally I send another memory start command to the 24C followed with the control byte (A1 hex) so that I can read from it.

At this point I am at "LOOP2" in the program. The program should loop at this point till RB2 goes low (SW1), then I call a delay ( which should eliminate any switch bounce), check the status of the other 2 switches then turn on my LED and, yes I clear "count1" again. I next call"ROTATELEFT1" ( which is just below this section of code) which sets up RC7 as an input and thru a loop will (hopefully) retrieve the word from the 24C and put it in the variable "chipdata", set PORTC as outputs and send an ACK bit back to the 24C. Then I return from the subroutine and call "DISPADD" which is a lookup table for the display address which depends on the value of the variable "count". After this is sent to the display, I take what is in the variable "chipdata" and write that to the display. This should happen 8 times, to get the 8 words from the 24c and display them in the proper display locations. The only time I vary from this loop is if the variable "count " is 3 which is the 10's hours location. The RTC puts out an extra bit in the third bit location to set AM or PM when used in a 12 hour mode This subroutine basically strips out that bit from the variable "chipdata" and also writes AM or PM to the display depending on the bit. This subroutine works just fine in the other part of the program where I read the data right from the clock chip, however by writing this, and explaining how this sucker is supposed to work that subroutine might be a good place to start.

I will give some time to changing the XOR's and see if that will make some progress.

Ernie
Basically what those pins are for is so I do not have to move the PIC from and to my bread board. I end up screwing up to many chips that way. As far as in circuit debugging, I would love to be able to do that, just don't know how and what I would need to do that. I have a PICkit2 to program ( just got it a couple of months ago and really don't know if I can use that), had to replace an old one I built a couple of years ago, had no serial port on the new PC.
 

jpanhalt

Joined Jan 18, 2008
11,087
The PK2 can be used to debug the 16F870 in system(while working) and will allow one hardware breakpoint in that configuration in MPLab IDE 8.92. I don't know about MPLAB X IDE.

John
 

Thread Starter

Retiredguy

Joined Feb 24, 2007
28
John,
I am running MPLAB IDE ver 8.86. I will have to do some reading and see if I can figure out how to do it.
Thanks
Mike
 

jpanhalt

Joined Jan 18, 2008
11,087
I never discourage reading the manual. If you have used MPLAB SIM the steps will be familiar. Click on debug mode, then debugger, then select tool in the dropdown menu, then PK2. From there, doing in-circuit debugging will be a relatively small step. The biggest difference you may notice is the limited number of breakpoints you have. Also, after every build, you cannot just run the debugger as you do in MPLab SIM. You have to actually reprogram your chip.

John
 

takao21203

Joined Apr 28, 2012
3,702
Well, after a month of trying to get this thing to work

Assembler.

I2C can be done as little as 90 words (readonly), for instance you can toggle the tristate.
I have done I2C a few times and of course have experienced lockup.

There are different approaches but one could be an interrupt watchdog.

Then I had a board with 18F PIC and TFT, if you'd remove any of the serial FLASH or EEPROM,
it would recognize the removal.

You could even expect some signature to be read at end of flash records, then also recognize if it doesnt appear within a timeframe.
 

Thread Starter

Retiredguy

Joined Feb 24, 2007
28
Well, finally figured it out. It was the memory chip posting a bit on the output of the port that I was using for the data buss for the display and RTC (RC7). Seems that an extra unwanted bit can screw up everything. Just wanted to say Thanks for the help.
Mike
 
Thread starter Similar threads Forum Replies Date
P Microcontrollers 6
EricFa Programming & Languages 10
T Microcontrollers 2
Top