Display corruption

Discussions related to the firmware code development
Post Reply
VK3KYY
Posts: 1658
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia
Contact:

Display corruption

Post by VK3KYY » Fri Jan 24, 2020 3:27 am

Both Daniel and I have been investigating the display corruption which happens occasionally.

Unfortunately neither of us has managed to fix this problem, and I'm not entirely sure we know what is causing it.

The problem seems to happen mainly on the TX screen because the screen is updated frequently to show the microphone audio level bar graph as well as the 'Talk timer'

The problem can also occur during Rx, and is possibly worse when the Rx signal level is constantly changing.

My best guess about this, is that the display controller IC, does not like the data flow being interrupted when a DMR signal is processed, and possibly the "command" parts of the display update, where the current 'row' and pixel numbers are updated, gets miss interpreted by the display controller, so that the wrong part of the display is updated.

However, work-arounds to fix this problem, including completely re-rendering the display, if the update was interrupted by a DMR IRQ, don't seem to solve the issue. Nor does re-sending the location command if it was interrupted by the DMR IRQ.

Nor does waiting for a gap between DMR IRQ requests (as they normally arrive on a regular basis)

Daniel tried using a mutex to prevent the DMR IRQ runing while the display being updated, however this caused problems with the DMR audio, and I don't think this is likely to be a viable solution, as the DMR timeing and hence the response time of the DMR ISR's is critical and can't be delayed.
I don't know whether even using the mutex completely solved the problem, because it only occurs randomly can it can take several minutes of transmission before the problem is observed.

Overall, I think potentially the bug is not being caused by what we think it is. Hence our attempts to fix it have failed.
I will probably be forced to solder some wires to the display interface board to look at the clock and data signals, but this is a pain to do, and its generally easier to try a solution and see if it fixes things.

User avatar
m1dyp
Posts: 335
Joined: Sat Nov 16, 2019 8:03 am
Location: Hertfordshire, U.K.

Re: Display corruption

Post by m1dyp » Fri Jan 24, 2020 4:01 am

its usually very temporary for me, about half a second but very rare, its not a big issue IMHO

its a great radio with opengd77 and this little glitch i can live with :mrgreen:
73 de Ken :D

VK3KYY
Posts: 1658
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia
Contact:

Re: Display corruption

Post by VK3KYY » Fri Jan 24, 2020 4:03 am

m1dyp wrote:
Fri Jan 24, 2020 4:01 am
its usually very temporary for me, about half a second but very rare, its not a big issue IMHO

its a great radio with opengd77 and this little glitch i can live with :mrgreen:
Its one of those annoying things which looks simple to fix, but ends up being difficult and taking ages.

User avatar
DG1YFX
Posts: 23
Joined: Fri Dec 13, 2019 11:16 pm
Location: Wiesbaden, DE
Contact:

Re: Display corruption

Post by DG1YFX » Fri Jan 24, 2020 9:16 am

In fact, the issue that the second counter on TX can be heard on audio makes it even stranger. Could be a hardware issue.

73s,
Jens

VK3KYY
Posts: 1658
Joined: Sat Nov 16, 2019 3:25 am
Location: Melbourne, Australia
Contact:

Re: Display corruption

Post by VK3KYY » Fri Jan 24, 2020 9:36 am

DG1YFX wrote:
Fri Jan 24, 2020 9:16 am
In fact, the issue that the second counter on TX can be heard on audio makes it even stranger. Could be a hardware issue.

73s,
Jens
I've not noticed the second counter being heard on the audio, but its not a big surprise. Its probably supply noise generated by either the UC1701 display controller or the MCU, which is being detected by the audio input DAC.

Post Reply