| Robbles | Posted: 1 Nov 2021, 03:38 PM |
|---|---|
 Member Posts: 6 Joined: 9-May 20 |
Hi, well, my clock didn't change :( It continued displaying BST time along with the BST lamp. Even after being power cycled it continued. OK, firmware? I updated the firmware some time back to use an external crystal ( issues documented here with the ATMega frequency ) but had been fine on BST during the summer. So, I have today updated the firmware to the London hex compiled 12 months ago. Fuses set at CF,DF,FF,FF. Now the time is correct, but there is no lamp lit for the timezone flag ( not GMT or BST. ) The LEDs themselves have not failed, tested quickly with a coin battery. Thoughts? Advice? Rgds, R. Last edit by Robbles at 1 Nov 2021, 05:45 PM ------------- |
| [top] | |
| mit | Posted: 1 Nov 2021, 07:58 PM |
 yeah whatever Admin Posts: 566 Joined: 4-May 16 |
Ah, I apologise, I know exactly what's happened here. For the two extra features I added ("permanent summer time scenario" and "UTC override mode") I made use of the spare pins which would otherwise be used for the crystal. This was only to make it easier to solder to them. But with the crystal fitted the chip will have become confused. When I get a spare moment, maybe tomorrow, I'll make a new branch of the firmware which uses different pins for those features. ------------- |
| [top] | |
| Robbles | Posted: 1 Nov 2021, 08:07 PM |
|
Member Posts: 6 Joined: 9-May 20 |
Hi, np - I was just coming to post that I had seen the same thing in the updated assembly instructions :) and that RTFM should be applied to me with the user compliance bat... It would be great to get a firmware that would work in my scenario - however 1. I think this is very much a corner case - there can't be many of us running the external crystal and 2. it's minor cosmetic at this point and for about six months moving forward so very not an urgent fix me now now now kind of issue. Rgds, R. ------------- |
| [top] | |
| Robbles | Posted: 2 Nov 2021, 09:23 AM |
|
Member Posts: 6 Joined: 9-May 20 |
For info ( if anyone stumbles across this after having the same issue ) I have for the momentreverted the firmware to version 4d9bc8d dated 18th April 2019 and I'm back up and running with the GMT/BST indicators fine. ------------- |
| [top] | |
| mit | Posted: 10 Nov 2021, 04:48 PM |
|
yeah whatever Admin Posts: 566 Joined: 4-May 16 |
I've added a bunch of extra build files in a subfolder called "with_crystal". These have the pins changed for those two problem modes. UTC Override is moved to pin PD1 (pin 3 of the chip, just next to the crystal pin) and Permanent Summertime is moved to PD3 (pin 7 of the chip). Only briefly tested it and I could do with cleaning up the makefile but it should mean you can run an up-to-date version of the firmware without problems. ------------- |
| [top] | |
| Robbles | Posted: 11 Nov 2021, 11:58 AM |
|
Member Posts: 6 Joined: 9-May 20 |
Hi there :) thanks for that - I have just flashed the london.hex to the chip, it seems to show the current / correct time, but there is no GMT/BST flag lit. Rgds, R. ------------- |
| [top] | |
| mit | Posted: 20 Nov 2021, 05:29 PM |
|
yeah whatever Admin Posts: 566 Joined: 4-May 16 |
Sorry it took me a while to respond. If neither light is illuminated, that means it's still in UTC override mode, so it won't switch to BST in summer. I just tried it out on my clock here and it seems to be fine. Can you double check: - that you flashed the correct image ( build/with_crystal/london.hex ) - that pin 3 of the chip isn't shorted to pin 4 or pin 2 ------------- |
| [top] | |
| Robbles | Posted: 20 Nov 2021, 07:53 PM |
|
Member Posts: 6 Joined: 9-May 20 |
Hi Tim, for sure I did use the correct hex, however I have just pulled it again and flashed - sha256 cf20ad4881449c2b2a3837500664b3b1c454e3c09ea6dfea50f0b4c4f0afbd62109f417932c0cd507dca52a676cb85a9883b7e01ff99de61e72d211e0e7e741b london.hex behaviour is now "more" expected but in some ways worse - the cold start time for the GPS is now of the order of 5-10 minutes before any time is shown on the display, now after 15 minutes it still hasn't moved to a lock with pps - the previous firmware this was at most 2 minutes to time display. I do however this time around have the GMT(UST) flag lit. Just a quick check - the fuses are set as Low 0xCF High 0xDF Extended 0xFF Lock 0xFF - I flash on a TL866II plus. I have the clock on a controlled switch so it's only operational when I am present / awake so the cold start-up time is not a one time hit for me - I'll revert to the previous firmware again, it seems to be working fne and I think that I can do without the new bells and whistles :) And after reverting - it got time on the display in under 60 seconds ( although PPS took circa 5 minutes ) Rgds, R. ------------- |
| [top] | |
| mit | Posted: 20 Nov 2021, 10:02 PM |
|
yeah whatever Admin Posts: 566 Joined: 4-May 16 |
That's unexpected, I'm not sure what could be causing that. Yes, those fuses are the same as what I used. I may take another look into this at some point, but if you're happy to live with the old version for now then I might leave it. Hmm, one thing it might possibly have been, there is the small supercapacitor on the GPS module that lets it do a warm start. If, during the flashing process, some of the pins got momentarily shorted together, maybe that could have cleared the ram and it would have to do a cold start, which can take much longer. It is very hard to debug this sort of issue though. ------------- |
| [top] | |
Sign in to post a reply.