Radio always enters INPUT TEST SCREEN

[rogerclarkmelbourne]

Firmware version 2.11.88 (latest available) Bootloader version 5.04

Hardware

• UI Board: mcHF 0.6

My system info lists the touch screen as XPT2046, but the touch calibration displayed errors of position out of range, so its possible my touch screen is faulty

Backup battery not fitted.

Describe the issue:

After several months of not using the radio...

After turning the radio on, it displays the "TOUCH CALIBRATION" screen even though the radio is not fitted with a touch screen. Pressing power to boot normally, boots into the "INPUT TEST SCREEN"

Rebooting either using the power or "band -" does not fix the problem.

I upgraded to the latest available build of firmware (2.11.88), and after rebooting multiple times, and leaving the radio powered for 1 hour, I saw a message about the firmware having been updated, and after that the radio now boots normally, and does not display the Touch Calibration or Input Test screen

[sp9bsl]

Hello Roger, looks like your touchscreen controller sees the touchscreen pressed. Have you the rig closed in a case? If yes - maybe a case issue around the display window.

73 Slawek

[rogerclarkmelbourne]

@sp9bsl

I've opened the rig many times.

I opened it today, when I noticed this problem, but removing the case and also wiggling the touch screen did not make any difference

The display looks like it has 3 or 4 connections to a touch screen overlay, but the touch screen calibration displays some message about the touch screen position being beyond limits.

I've had the radio turned off for about 1 hour, and when I turned it on again, I now immediately get the "TOUCH CALIBRATION" screen.

I think the touch screen is possibly defective, and perhaps the firmware is detecting a touch during bootup, which causes it to even the TOUCH CALIBRATION screen?

If this is what the firmware is doing, I don't think its ideal, because if the touch screen has a problem, then the operator gets locked out of the normal operation.

It would be better if the touch screen calibration was accessed by the menu system.

I suppose I'll either have somehow cut the lines to the touch screen overlay, or build a custom version which does not boot into the calibration screen.

73

Roger VK3KYY

[sp9bsl]

Indeed - the firmware does the touchscreen check during the boot up. We will consider the change of enter to touchscreen calibration, your problem is rare but as in your case - possible.

[df8oe]

This is not a firmware poblem but a hardware problem. Touchscreen is showing "pressed" if it is not pressed. I do not think we should remove tc calibration forcing because it is mandatory.

There are two solutions: 1) solve the tc issue (by swapping the defective LCD) 2) cut the line TP_IRQ

The last solution is like the hint "remove the wheels from your car" :) I would recommend solution 1)

vy 73 Andreas

[sp9bsl]

Roger, to disable reporting from touch screen controller, looking on the schematics of v0.6 - you can remove the R34a on UI board to disable the IRQ signal from the LCD module. By checking this pin, firmware knows about touchscreen was pressed.

Of course Andreas is right, replacing the LCD is best option :)

[rogerclarkmelbourne]

Thanks guys,

I'll see if I can get hold of another display + touch screen, but there are supply problems from China at the moment, because of the COVID-19 lockdown in Australia, with very few international flights available for goods transport.

I'll check the schematic. I'd rather not remove a surface mount resistor, as they are hard to refit. I'd rather add a try to pull the IRQ high on the side of the resistor next to the MCU.

I will probably try to rebuild the firmware to disable the IRQ.

I'm pretty sure I had one of my machines (linux) setup to build the firmware.

I also tried to import the eclipse project into the STM32CubeIDE (aka eclipse) that I already had setup on Windows, but it doesnt seem to import the project correctly, and seems to have no build targets, so I'll probably have to get the toolchain working again on Linux

Thanks again

Roger

VK3KYY

[rogerclarkmelbourne]

Guys.

FYI.

I've done a hack and recompiled the firmware.

I changed UiLcdHy28_TouchscreenPresenceDetection() to return false, and I think this fixes the bug for me.

I did consider changing UiDriver_Init() so that the initial check of calibration was not performed, but I realised that on my radio, I couldn't even turn the radio off using the power button, because of the problem with the screen.

So it was safer just to force mchf_touchscreen.present to always be false.

[df8oe]

Hi Roger,

again: there is no bug in the firmware. You do have a defective hardware and you have found a way to do a software workaround instead of the necessary hardwair repair ;) Of course that fixes your problem - but it will not reach official firmware to bypass this adjustment procedure...

[rogerclarkmelbourne]

OK. Thanks for replying. I'll close this issue.

[rogerclarkmelbourne]

Sorry to be a pain, but I can't find a BOM for the radio, the MCHF site is not very user friendly.

Do you have a link to the BOM or know what the part number is of the display + touch screen ?

[df8oe]

Hi Roger,

sorry - we don't have a BOM, too. But I can give you part-no. of LCD: it is HY28B and you can get it from here: https://www.hotmcu.com/28-touch-screen-tft-lcd-with-all-interface-p-63.html

vy 73 Andreas

[rogerclarkmelbourne]

Hi Andreas

Thanks

BTW.

Sorry I can't submit a PR to overcome the problem caused by my faulty screen, but I don't know enough about your codebase.

I hope in the future to be able to contribute, but because I administer and develop firmware for some DMR radios. https://github.com/rogerclarkmelbourne/OpenGD77 this takes most of my spare time.

[df8oe]

Hi Roger,

of course I know who you are and I own a GD77 running OpenGD77 by myself :) Many thanks for your work there!

We have thought about handling of such hardware-issues in the past and we came across

• not to ignore them
• not to add a feature to bypass tc tests if magic buttons are pressed at boot

If you are running an unadjusted tc you cannot use it and you get strange results when trying to operate via tc. So tc adjustment is mandatory...

We came along to leave it as-it-is. it is a hardware-issue and UHSDR pops you up to this. You can decide to swap the LCD or disable tc by cutting TP_IRQ line. A hardware fault should be overridden by hardware - not by software.

[rogerclarkmelbourne]

Thanks Andreas

Yes. This is definitely a hardware fault, so not something which requires a firmware fix. I'll order a new display.

I'm glad you are enjoying the OpenGD77 firmware.

73

Roger

[rogerclarkmelbourne]

Guys, Sorry to be a pain, but I think there may be a small problem with the touch screen presence variable being used before its initialised.

As far as I can tell, the touch screen presence is initialised here

https://github.com/df8oe/UHSDR/blob/active-devel/mchf-eclipse/drivers/ui/lcd/ui_lcd_hy28.c#L2822

Which is called from here

https://github.com/df8oe/UHSDR/blob/active-devel/mchf-eclipse/drivers/ui/ui_driver.c#L954

However, if you look at line

https://github.com/df8oe/UHSDR/blob/active-devel/mchf-eclipse/drivers/ui/ui_driver.c#L919

In the same function, you appear to be using mchf_touchscreen.present before its been initialised. (I know as a global structure, it may be initialised to false but it doesn't seem to be logical to use it before its formally initialised)

I know I have a hardware error on my radio, but my fix to modify the touch screen detection to return false, didn't work correctly, hence I tried to track down why that's the case.

[sp9bsl]

Hi Roger, the mirtemp was used in very old touch screen service algorithm. Since 2017 is not needed because new algorithm does mirroring detection by math. All related code should be removed. Thanks for discovering this!

73 Slawek