Can't get Flick Zero to work reliably

[wurls80]

I bought a Flick Zero to play with, with the thought of integrating into a magic mirror type project.
Have setup a raspberry pi 2B as a fresh install, fitted a Flick Zero and installed the code and demos.
i2cdetect always shows it is connected.
But the demo's wouldn't work.
After a few attempts at running it (using Geany not Thonny) the snail demo started to work. Then so did the others.
Installed MagicMirror software and the MMM-flick-gestures module, and all worked as it should. This includes directly touching the flick board and being a few cm above it.

But then it stopped working again. I got a pyShell finished with err undefined message from the magic mirror, so assumed it was a problem with that module.

Went back to the flick demo's, the code runs without flagging any errors but aren't registering any gestures.

I've reboot and shutdown and restarted, to no change to the flick performance. interestingly I can run the magic mirror without seeing the pyShell error any more, but I get no response from the Flick Zero.

Everytime I run i2cdetect command it finds it (at least, I get the following):
i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- 42 -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Tried flick_img.py and it started working; but has since stopped. Still showing as connected.

At first I thought when I set it up that I'd missed something in the install which I then corrected but now I'm thinking it's a reliability issue somewhere else. I tried resetting the gpio: get the same response from i2cdetect as above but it doesn't make the gestures work. I can't seem to identify something software related, but the fact it's reporting it is connected is throwing me, otherwise I'd think it's hardware issue.

This is when directly over the flick board, or touching it, with nothing inbetween.

What would you suggest for next steps? or is this normal? Many thanks.

[tvoverbeek]

The current kernel lowers the clock speed when the cpu load is low and increases it when the load increases.
The I2C clock varies with the cpu clock. It might be that te varying I2C clock speed causes your problems.
You could try the following:
In /boot/config.txt add the line force_turbo=1. This fixes the cpu clock speed and hence the i2C clock.
See if this helps..

[wurls80]

Hi thanks for the quick response.
I've changed config.txt as suggested and reboot but issue still remains - flick board is showing as connected, but the flick demos and flick_img.py aren't registering any gestures.

[wurls80]

Is there a fundamental reason why the flick zero won't work with pi 2B v1.1? I tried the board with a Zero W and it worked perfectly.
I've tried running the pi 2B with no usb Wi-Fi, keyboard or mouse plugged in and it makes no difference to the flick zero (I.e. no response to gestures seen by the pi). I haven't tried overclocking the pi 2B to 1GHz like the zero W to say if that makes a difference.
If there isn't a fundamental difference then thing I'm down to fault finding the GPIO header. Tested all 5V and 3.3V pins and their fine, not quite sure how to test the others (short of trying other Hats on it).
Just still find it weird that i2cdetect responds correctly but the pi 2B picking up output from the board is erratic at best.

[wurls80]

To try and fault find further I came across the pigpio library and gpiotest script - I wanted to try and fault find the gpio.

I installed the pigpio library as described here: http://abyz.me.uk/rpi/pigpio/download.html

Under the "To Check the Library" section there are a number of commands that run a number of tests to check interfaces. I've run on the pi 2B and then repeated with the Zero W (same power supply, same SD card - so same software packages installed).

Results as follows:

Pi2B
sudo ./x_pigpio # check C I/F

• Fails test 5.4 (got 25, expecting 50)
• Fails test 5.11 (got -142, wave tx busy, serial read:0)

Run daemon
./x_pigpiod_if2 # check C I/F to daemon

• Fails test 5.4 (got 26, expecting 50)
• Fails test 5.10 (wave tx busy)
• Fails test 5.11 (wave tx busy)

./x_pigpio.py # check Python I/F to daemon

• Fails test 5.4 (got 26, not 50)
• Fails test 5.10 (wave tx busy)
• Fails test 5.11 (wave tx busy)
• Fails test 5.26 (got 25, expecting 50)
• Fails tests 13.7 to 13.10
• Fails test 13.12

./x_pigs # check pigs I/F to daemon

• SLR-f fails

./x_pipe # check pipe I/F to daemon

• SLR-f fails

sudo ./gpiotest

• No gpio fails.

Zero W
sudo ./x_pigpio # check C I/F

• All pass

Run daemon
./x_pigpiod_if2 # check C I/F to daemon

• All pass

./x_pigpio.py # check Python I/F to daemon

• All pass

./x_pigs # check pigs I/F to daemon

• All pass

./x_pipe # check pipe I/F to daemon

• All pass

sudo ./gpiotest

• No gpio fails.

The only difference is the hardware but I think the above seems relevant - only I haven't yet managed to find anything to indicate what the failed tests on the pi2B might imply. I thought I would post in case anyone else with more experience can suggest anything to point me in the right direction? Many thanks.

[wurls80]

So today's update. Keeping this up to date as It's a helpful way of collating my thoughts, flick supplier has the link and hopefully it will help others in the future. I've found various other posts with similar issues but no solution.
So back to today. With assistance from pigpio support have confirmed that my test results are weird, but don't identify a problem with i2c.
In parallel and knowing that the pi2B and Zero W have different processors I wanted to see what i2c baud rate was being used by each, to see if that was a difference that could be an issue. Dmesg provided no information, so with the pigpio library installed I also installed their piscope software.
This confirmed two things:

• when the HAT works in the Zero W it is using a baud rate of 100kHz
• when the HAT doesn't work it is sent the reset command and responds but then nothing happens (see attached picture)
  

Having found the baud rate the Zero W was using successfully with the HAT I added it to my boot/config.txt booted it up in the pi2B and what do you know - it worked!
However success was short lived. In getting the baud rate there where times I saw the fault with the ZeroW, which i hadn't seen before. The pi2B was working about 50% of the time at first but that has now dropped off. I wondered again whether it was having usb keyboard/mouse etc plugged in but cant replicate it. So if it was a physical issue then I think It's just the act of moving it around - but I don't think it is as I don't think I've ever had it stop working once the HAT is in use and working. It just either works when you start to use it or it doesn't.
So I think all of the above points to a hardware fault, but unfortunately not a dodgy gpio connection. I was looking at pimoroni's skywriter HAT which looks very similar and on their support forums they do state that the underlying chip can sometimes just lock up, and it doesn't seem to be a fault that they can offer a solution to.
So I think next steps I could do:

• consider installing skywriter libraries and examples and see if that makes any difference (I think unlikely)
• try to fault find the hardware. Could try and prove the issue is the HAT by showing other HATs that use i2c work with the pis, but this might not be reliable as they might work differently; or It's buy new hardware and see if that works. Needs a bit of thought.
  There is every chance I have more than one fault - something isn't right with the pi2b, but I do think from the above that the flick HAT just doesn't get It's chip working so you don't see any response. I don't think you can fix this with code unless you know to expect a response (then potentially in your code you just keep resetting it until it responds).
  All thoughts welcome

[wurls80]

Having looked at the datasheet for the MG3130 chip https://www.microchip.com/wwwproducts/en/MGC3130#datasheet-toggle
Which is what the HAT uses I couldn't help but notice some similarities between my "it not working" i2c trace and their scan and looking for presence of a finger.
I've tried holding finger still over HAT for longer when the script starts up, flicking in and out slowly, but no luck.
I tried adjusting the position of the HAT to see if it is a dodgy connection at the header. What I've discovered is:

• if it doesn't work when you run the demo it won't start working
• if it does work when you run the demo then if you move the HAT it keeps working. Until you quit the demo and then run it again, when it won't work.
  Might be coincidence. But the issue does appear to be around getting the HAT to recognise presence of a finger and then monitoring gestures.

[wurls80]

So. Bit more reading around and I've come across a number of other issues logged which appear to have the same outcome as what I'm seeing:
#14
#16
#31
#33
#39

Didn't think to look in the "Closed" issues, shame that there doesn't seem to be a clear solution.

Either way it looks like it is the Flick Zero board that is at fault - something faulty with chip initialisation is mentioned in the most recent one: I suspect from what I've seen above that the issue is the chip not waking up when it completes it's approach scan on the initial approach for some reason.

In the above firmware reset was seen to solve the problem (though it isn't clear why, as in issue 14 it's just the same firmware version that is flashed, not an updated one from what I can see). However from issue 16 onwards there is somewhat misleading guidance over whether firmware reset should be attempted or not. Seems to say you shouldn't do it unless told to by Pi-Supply.

I have contacted Pi-Supply (bought this board from them months ago so way past stated 3 months return) but was told due to other reasons it was unlikely their technical team would look at it. But that keeping the github issue up to date was best way to keep them informed.

So this is me keeping it up to date. Am considering whether I try firmware reset as not sure I have much to lose. If anyone does have the opportunity to provide input that would be appreciated.

[ga65w]

Taking up the invite to provide some input:
I purchased a Flick HAT last week. It is connected to a Pi3. Flick-demo works intermittently. I could not see any logic as to when it would work and when it wouldn't. All I do is run flick-demo. If it doesn't work I do a Control-C and then re-run. Randomly, it will work. Once it is working it continues to work until program exit. The Pi never has issues communicating with the HAT as the box with firmware details is always populated in flick-demo.

I've tried the board in a Pi4. It never worked (detecting gestures) but perhaps I didn't persevere enough.

I wrote the above a couple of days ago but I didn't post as I thought I would give the board one more day of testing. Yesterday it worked most of the time and I even used flick-armcontrol successfully. I couldn't see any logical reason why it had suddenly started working so well. Today it isn't working at all. So what is the difference between yesterday and today?

I'm returning the HAT. It is immensely frustrating.

[wurls80]

Thanks for the input though shame we're seeing what appear to be the same issue. Which also seems to have been seen by the other issues raised.
I feel your frustration!

[wurls80]

So reflashed the firmware. First attempt saw lots of read access errors - immediately did it again and it reflashed perfectly.
Started up the flick demos and they worked perfectly!
Flick-demo reports the same firmware version, so it is strange why it would now work. I still think the issue is some times the chip doesn't recognise approaches and doesn't come out of the approach scan, and you have to restart the code to make it work. It's weird that it either does it or doesn't - if it works when the code is running it seems to keep working, if that makes sense.
However.
I've been testing it over the last few days. First time after boot it doesn't normally work, then run the code again and it does. At first it would work about 90% of the time you run the code. But the fault seems to be getting more frequent again - was nearer 50% when I stopped today.
I'll keep going with it but I'm not confident It's going to be reliable, if the pi/code that's running it is switching on and off regularly.

[ga65w]

Received replacement Flick HAT yesterday. Plugged it in but didn't fix it with standoffs. It worked first time and continued to work through a number of cycles of switching Pi off and then switching it back on again. Switched on Pi this morning and again Flick HAT worked straight away.

I am now assuming that all is well and will therefore fix HAT more securely with standoffs.