Here I'm going to talk about a month rollover bug that my clock had been experiencing.
In a previous post I spoke about an issue that came about when I showed the clock to a friend. When the clock advanced onwards from 23:59:59 on, say, the 31st day of a month to what should have been 00:00:00 on the 1st day of the following month, it actually advanced to day 0 - which is something that wasn't supposed to be able to happen.
I'd designed in a preset input to the first stage of the day-of-month units counter such that when ever certain reset signals were asserted to reset the counter back to the start of the month, the units counter should have been pre-loaded with a 1.
But I've already discussed and fixed that issue. This post pertains to a different rollover bug that I encountered after I had debugged and fixed the one above.
And the story behind this one is that when the clock is on day 29 of a month, and it needs to advance to day 30, it would actually advance to the next month and again to day 0, instead of the 30th.
My suspicions about why this was happening surrounds the use of ripple counters in my clock. I suspected that because of the way ripple counters work, in that it can take "some time" for a change starting at the least significant bit to make its way through all of the stages of the counter. What this means is that for a very brief period of time the counter can represent a number of different values in quick succession as the flip flops transition between different states.
And because of this, I figured that the block of combinational logic that determines what day of the month it is, and based on the "length-of-month" input (30 day, 31 day or February), at some point in time the state of the counters was such that the reset logic figured that the date actually needed to advance to the next month instead of letting the counters advance to the next day.
To test this theory I needed to probe around the reset circuitry in the clock to see what it was doing. Specifically I was looking at the output of GATE68 in the calendar module. The output of this gate will be high when the day of month counter should reset and advance to the next month.
I set up my oscilloscope to trigger on a high going edge of the output of this gate, set the clock to 23:59 on Jan 29 and then let it run. The sequence of events is as illustrated below.
As you can see (although the scope probe wasn't connected in these photos) that once the clock advances past 23:59:59 (to what would technically be 24:00:00) the reset logic generates a pulse which causes the day of month counter to reset to 00 and the month counter to advance to the next month.
So I thought about it for some time, and I reckoned all that might be needed would be to add a small capacitor to this reset signal, such that while the ripple counters are sorting out their final state, if the reset logic should happen to generate a pulse during this period, the initial bulk of that pulse should be absorbed by the capacitor such that only once the ripple counters settle down, and if their state represents something which should cause a reset, then the reset signal will remain high for a significantly longer period of time - long enough to fully charge the capacitor and thus allow the reset signal to actually cause a reset.
So I tried this out:
In this photo you see a little grey probe sticking out the left hand side of the clock. This is connected to the output of GATE145 in fact. The orange wire connects to a 1nF capacitor, the brown wire connects to VSS (ground), and the green wire connects to my scope.
As you can see on the face of the clock, this did indeed seem to do the trick, as the calendar had advanced correctly from the 29th to the 30th and remained within the same month, instead of moving to the next month.
I do still see a small rise in the reset signal, I guess 1nF is only just enough to cover this, but at about 1.5V its not high enough to drive any MOSFETs and cause a reset.
For completeness, heres a photo of the newest addition to the clock (the little orange blob), tucked away all nice and cozy in there:
The schematic for the calendar module has also been updated to reflect this recent addition. And with that, I am no longer working on any issues - the clock works and functions as it should. Only time will tell if anything else pops its head up.
In a previous post I spoke about an issue that came about when I showed the clock to a friend. When the clock advanced onwards from 23:59:59 on, say, the 31st day of a month to what should have been 00:00:00 on the 1st day of the following month, it actually advanced to day 0 - which is something that wasn't supposed to be able to happen.
I'd designed in a preset input to the first stage of the day-of-month units counter such that when ever certain reset signals were asserted to reset the counter back to the start of the month, the units counter should have been pre-loaded with a 1.
But I've already discussed and fixed that issue. This post pertains to a different rollover bug that I encountered after I had debugged and fixed the one above.
And the story behind this one is that when the clock is on day 29 of a month, and it needs to advance to day 30, it would actually advance to the next month and again to day 0, instead of the 30th.
My suspicions about why this was happening surrounds the use of ripple counters in my clock. I suspected that because of the way ripple counters work, in that it can take "some time" for a change starting at the least significant bit to make its way through all of the stages of the counter. What this means is that for a very brief period of time the counter can represent a number of different values in quick succession as the flip flops transition between different states.
And because of this, I figured that the block of combinational logic that determines what day of the month it is, and based on the "length-of-month" input (30 day, 31 day or February), at some point in time the state of the counters was such that the reset logic figured that the date actually needed to advance to the next month instead of letting the counters advance to the next day.
To test this theory I needed to probe around the reset circuitry in the clock to see what it was doing. Specifically I was looking at the output of GATE68 in the calendar module. The output of this gate will be high when the day of month counter should reset and advance to the next month.
I set up my oscilloscope to trigger on a high going edge of the output of this gate, set the clock to 23:59 on Jan 29 and then let it run. The sequence of events is as illustrated below.
As you can see (although the scope probe wasn't connected in these photos) that once the clock advances past 23:59:59 (to what would technically be 24:00:00) the reset logic generates a pulse which causes the day of month counter to reset to 00 and the month counter to advance to the next month.
So I thought about it for some time, and I reckoned all that might be needed would be to add a small capacitor to this reset signal, such that while the ripple counters are sorting out their final state, if the reset logic should happen to generate a pulse during this period, the initial bulk of that pulse should be absorbed by the capacitor such that only once the ripple counters settle down, and if their state represents something which should cause a reset, then the reset signal will remain high for a significantly longer period of time - long enough to fully charge the capacitor and thus allow the reset signal to actually cause a reset.
So I tried this out:
In this photo you see a little grey probe sticking out the left hand side of the clock. This is connected to the output of GATE145 in fact. The orange wire connects to a 1nF capacitor, the brown wire connects to VSS (ground), and the green wire connects to my scope.
As you can see on the face of the clock, this did indeed seem to do the trick, as the calendar had advanced correctly from the 29th to the 30th and remained within the same month, instead of moving to the next month.
I do still see a small rise in the reset signal, I guess 1nF is only just enough to cover this, but at about 1.5V its not high enough to drive any MOSFETs and cause a reset.
For completeness, heres a photo of the newest addition to the clock (the little orange blob), tucked away all nice and cozy in there:
The schematic for the calendar module has also been updated to reflect this recent addition. And with that, I am no longer working on any issues - the clock works and functions as it should. Only time will tell if anything else pops its head up.
- GitHub repo
- calendar-module.sch EAGLE schematic file
- calendar-module.pdf
No comments:
Post a Comment