OpenGD77

That's curious Roger, so maybe it's a slight variation in the radio's hardware that affects some but not all rigs. With the version 2 debug firmware that Alex posted in the thread I left my GD77 off for 2.5 hours and powered it up about 10 minutes ago. It came up without any issues at all. Note that the last OpenGD77 normal release would lockup the keyboard every time with that scenario. I used the keypad to run through every menu item and then set it in scanning mode with DMR and analog and it behaved perfectly. It is still merrily scanning away right now. So... maybe the changes Alex made resolved it? Not sure but I'll leave the debug version 2 firmware in the radio and let it sit overnight to see if it behaves tomorrow morning.

73, Rob W1AEX

Rob

Its certainly a strange one.

I wonder if its related to the temperature of the radio.

Roger,

It could be temperature related with mine, as it only locks up when the radio has not been used for a couple of hours. However, it always comes up correctly with the first restart, although both of John's (N1ID) are more fussy and require multiple restarts before the keypad begins to function.

Rob

You could try putting it sealed box or plastic bag and put it in the fridge for a while, or alternatively (safer) warm it up before turning it on, after leaving it a while.

Though I would have though leaving it on charge may warm it up a bit

I have been on the newest debug code and it has not happened yet. Had the radios off for a couple of hours and all ok so far

The debug version seems to fix it.
I will create a pull request for the changes.

I have been running the second debug release all day long Alex and it has been flawless. No startup issues even after leaving the radio turned off in a cold room for 4 hours. Thanks for chasing this one down.

73, Rob W1AEX

Pull request is on it's way.

There was a bug in the keypad debounce part, that could lead to the lockup.

The keypad function reads the I/O-pins and after 20ms reads the pins again.
If these values are the same, it's a valid keypress, otherwise it's not.
In the first case the key is processed, in the second it should start over.

For some reason I removed the second part. So if a key bounces longer then 20ms the whole system locks.

If the MCU is powered on, the I/O-pins need some time to stabilize. There a resistors, capacitors and other parts that need some time.
After this time the I/O-pins deliver reliable values. The time depends on the hardware, temperature, voltage, solar irradiation.
If the keypad is read within this time, the debounce code starts working and locks the keypad.

I hope this was understandable, as I am not used to describe technical coherences in English.


And now time to go to bed.

Thanks Alex

I wonder if also we need to investigate whether it is necessary, or possible, to turn on some pull-up or pull-down resistors in the MCU. I know some MCU's have that feature and I presume the MK22 must have that feature, but could not see any examples of it

I know one station had a problem with an old GD-77 where he was getting phantom key presses during DMR Rx, which I think must be caused by problems with the pull-up / pull-down's


Anyway. I think the code is now stable enough to at least update the "latest" version

https://github.com/rogerclarkmelbourne/ ... latest.sgl

If people test this and have no problems, it will become the new "stable" version.

oops, it seems to have mucked up my zones, the 80 cps reads the codeplug correctly but the radio displays them weird