Carton__
Posts: 16
Joined: Tue Nov 20, 2018 4:29 pm

Touch IC of official 7" being reset during burst/EFT at 7kV

Thu Jun 10, 2021 2:37 pm

Hi,

I've made a product embedding an official 7" touchscreen from RPF for a customer. Just one week before the launch, he came with a new requirement : the product has to pass EN61000-4-4 tests at +/-7kV level.... (WTF ?!). Prior to this the level was +/-1kV as for CE mark requirements for the class of the product...

Now I can almost pass this level of EFT/Bursts. The only thing going wrong is the display. The picture stays but the touchscreen is "disabled" after the test. So I assume it resets during the test and it's gone after this.

The only way of fixing this is powering down the device physically. A simple 'reboot' command doesn't work. I assume some initialization of the touch IC occurs in the firmware.

Does someone know a way to "fix" this ? I simply want to be able to "reset" the screen without human intervention (so B criteria and not C) and, best, being able to detect a reset touch IC so I can perform this only when needed.

Thanks for your help

aBUGSworstnightmare
Posts: 3152
Joined: Tue Jun 30, 2015 1:35 pm

Re: Touch IC of official 7" being reset during burst/EFT at 7kV

Fri Jun 11, 2021 7:40 pm

Maybe you shiuld have a look at the driver sources to see if there is a way of recovering it.

Well, that's quite a tough new requirement all of a sudden. Even if one has full contoll on all touch features/settings tuning them for EMC can be a big pain in the back ...
You should checj the official certificates https://www.raspberrypi.org/documentati ... formity.md; touch has not been tested for EN61000-4-4.

Carton__
Posts: 16
Joined: Tue Nov 20, 2018 4:29 pm

Re: Touch IC of official 7" being reset during burst/EFT at 7kV

Sat Jun 12, 2021 9:50 am

Maybe you shiuld have a look at the driver sources to see if there is a way of recovering it.
I've tried but I'm far from being an expert in Linux drivers. It will take me a lot of time and I'm not sure if I could succeed at all. That's why I'm asking for help.
Well, that's quite a tough new requirement all of a sudden. Even if one has full contoll on all touch features/settings tuning them for EMC can be a big pain in the back ...
It's not fair at all. We put all requirements in a contract. This one wasn't mentioned. After spending a lot of money, 7 months, stress and effort into certification and hardware improvement, I'm mad. But...Even it's not in the contract, a tiny company like mine can do nothing against a big old company with a great reputation...
You should checj the official certificates https://www.raspberrypi.org/documentati ... formity.md; touch has not been tested for EN61000-4-4.
I have the EMC test reports of the Official 7" touchscreen. It was tested at 0.5kV and 1kV levels. But, unsurprisingly, not above. Also their test setup is extremely different from the test setup of our product.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11459
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Touch IC of official 7" being reset during burst/EFT at 7kV

Sat Jun 12, 2021 2:02 pm

Does the screen go black, or just the touch element stop responding?

I'm guessing you're using the firmware drivers rather than KMS (no "dtoverlay=vc4-kms-v3d" in /boot/config.txt), in which case there is no reset at all.

I suspect that it's the Atmel controller on the display board locking up rather than the touch IC. It looks after power and backlight control. There's an EDT5406 touchscreen control chip that does the actual touch function, but if the Atmel is killed such that it hogs the I2C bus, then it's largely irrelevant.

The KMS kernel drivers could be convinced to do a reset, but if it's the Atmel then it'll have to be done by killing the power to it via some form of power switch on a GPIO, rather than just a simple command sequence. The DSI to DPI bridge chip, backlight, and touch chip then all need to be reinitialised too. It's not trivial to arrange.

If you add "dtparam=i2c_vc=on" to config.txt then you should get /dev/i2c-0 and /dev/i2c-10 enabled. The touch display is on /dev/i2c-10, but be aware that the firmware will be polling it too. When it's locked up report what "sudo i2cdetect -y 10" gives. If all addresses respond then the bus is locked (probably by the Atmel). If 0x45 responds, then that is the Atmel. If 0x38 responds, that's the FT5406 touch controller. You may get some odd timeouts where the ARM and firmware try using the I2C bus at the same time as there is no arbitration. You can enable the panel but disable the touch process by adding "disable_touchscreen=1" to config.txt
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Carton__
Posts: 16
Joined: Tue Nov 20, 2018 4:29 pm

Re: Touch IC of official 7" being reset during burst/EFT at 7kV

Mon Jun 14, 2021 10:08 am

Does the screen go black, or just the touch element stop responding?
The screen was turning black but, after taking measures to ensure a minimal distance between power supply cable and DSI cable, it's only the touch functionality that's missing after the 7kV bursts. My PCB design was not made to withstand such high levels.
I'm guessing you're using the firmware drivers rather than KMS (no "dtoverlay=vc4-kms-v3d" in /boot/config.txt), in which case there is no reset at all.
I was using the KMS drivers before but, after some issues with them, I switched back to firmware drivers. I'm compiling with Yocto on thud branch with meta-raspberrypi.

I suspect that it's the Atmel controller on the display board locking up rather than the touch IC. It looks after power and backlight control. There's an EDT5406 touchscreen control chip that does the actual touch function, but if the Atmel is killed such that it hogs the I2C bus, then it's largely irrelevant.

The KMS kernel drivers could be convinced to do a reset, but if it's the Atmel then it'll have to be done by killing the power to it via some form of power switch on a GPIO, rather than just a simple command sequence. The DSI to DPI bridge chip, backlight, and touch chip then all need to be reinitialised too. It's not trivial to arrange.

If you add "dtparam=i2c_vc=on" to config.txt then you should get /dev/i2c-0 and /dev/i2c-10 enabled. The touch display is on /dev/i2c-10, but be aware that the firmware will be polling it too. When it's locked up report what "sudo i2cdetect -y 10" gives. If all addresses respond then the bus is locked (probably by the Atmel). If 0x45 responds, then that is the Atmel. If 0x38 responds, that's the FT5406 touch controller. You may get some odd timeouts where the ARM and firmware try using the I2C bus at the same time as there is no arbitration. You can enable the panel but disable the touch process by adding "disable_touchscreen=1" to config.txt
This part is very informative. Thanks.
The probability of fixing my issue with software tricks is definitely extremely low.
As there is no easy solution, I won't inspect any further for the moment and try to convince them to drop this new 7kV requirement first as it was not written in our contract.
When I will have some spare time, I will try to play with this.

Thanks for the help!

Return to “Official Foundation Display”