iRiver H120 button problem

[tab]

I've got a strange problem with my H120 lately. Whenever I start Rockbox (configured to start in the file menu) it starts to scroll down like crazy without me pressing any buttons. After some seconds, this stops. But not completely, it still scrolls down one line every 5  to 10 seconds. When I start playback, it decreases the volume on its own. Again, this is normally done by the same button (Navi "down") as scrolling down in the file menu.

At first I thought my good old iRiver has a problem. But, booting into the original iRiver firmware it doesn't show a similar behaviour. No navi "down" actions without me really pressing the button. So what could this be? I've run Rockbox on the unit for several years now without any bigger problems. But this one is strange. Am I the only one who has this strange problem? Should I try to reflash the bootloader or completely remove the .rockbox directory and reinstall? Any hints?

tab

[LambdaCalculus]

What build and bootloader versions are you running?

[tab]

Hmm. Everything seems back to normal now after imstalling an older daily build and starting Rockbox. The problem might be database related. The odd behaviour started after I  selected all tracks of an artist and started playback.  Anyway, the old build from June 2nd doesn't have the problem while the latest daily still has it. It's too late here now for me to try out all builds in between. Maybe tomorrow if noone fixed it by tomorrow evening.

I used a build at least one day old when the problem first appeared. Bootloader version 6.

tab

[Lear]

I've got a strange problem with my H120 lately. Whenever I start Rockbox (configured to start in the file menu) it starts to scroll down like crazy without me pressing any buttons.

Interesting. This sounds very similar to a problem I had when I first tried building Rockbox using a newer version of GCC. Based on that, I'd try the daily build from June 13 and 14. If the problem starts with the second of those builds, I have something worth trying.

[tab]

Sorry for the delay, I tried to download the 13th daily build, but can't access the download site today

tab

[tab]

Well, now that I can download builds again, I can't reproduce the problem any more. I installed both builds, June 13th and 14th, did (I think) exactly the same that I did before. Nothing, no scroll down, no volume lowering, completely normal behaviour. I installed the latest daily now (June 16th) and will watch out for the problem to reappear.

tab

[tab]

ÃŽt happened again! This evening I downloaded a current build and at first everything seemd fine. Then I listened to an album while working. After some time I wondered, whether the album was already through because there was no music any more. Actually, it wasn't. Just the volume was something like -100 dB. After I stopped playback, the fast scrolling happened again in the menu. Now I've downloaded and installed the 20070613 daily build again for testing.

tab

[djnhudson]

Hi,

I can report that I've had the same problem with my H120 and Rockbox.  Just tried reloading the bootloader with version 6 and using version r13725-070627 of Rockbox to start fresh.  If I initialize the database, the highlight bar just keeps scrolling down, wrapping again from the top.  Same behaviour at boot time, I suppose it is loading the database at that time.  But even without initializing the database, Rockbox seems to detect a down button being pressed every ten seconds or so, which can be observed in menus, the file list, or as the volume decreasing steadily in the Now Playing screen.  If I boot back into the original firmware, everything is fine, which leads me to think it's a firmware issue and not hardware related.

I'm kind've new here, so I hope I haven't offended by just jumping in.  Just thought I'd add what observations I could to see if I could help.

[Multiplex]

This reminds me the discussion over in http://forums.rockbox.org/index.php?topic=7149.0 where a user was having trouble with buttons on the remote.

On the H120/H320 families most of the buttons on the main unit and remote are read using an analogue input and a chain of resistors connected to the buttons http://www.rockbox.org/twiki/bin/view/Main/IriverHardwareComponents#The_Buttons the CPU reads the Analogue input and compares it to a set of numbers to decide what button is pressed. For example below 1V it is left, between 1V and 2V it is right, 2V to 3V is up, and so on.

I'm wondering if on your unit(s) the value when no button is pressed is very close to the change over point to down button pressed and a litle bit of elecrical noise makes it look like the button is pressed every now and then.

You could try going to the system -> Debug (Keep Out!) -> View I/O Ports menu and look at the ADC_Buttons and record what the value is when there is no buttons pressed and then the down button - post the values here and when I can I'll see what the changeover points are in the source code. You exit the I/O Ports screen with the stop button.

This is just a theory of mine - it may be of no help at all ...

[Lear]

On the H120/H320 families most of the buttons on the main unit and remote are read using an analogue input and a chain of resistors connected to the buttons http://www.rockbox.org/twiki/bin/view/Main/IriverHardwareComponents#The_Buttons the CPU reads the Analogue input and compares it to a set of numbers to decide what button is pressed. For example below 1V it is left, between 1V and 2V it is right, 2V to 3V is up, and so on.

I'm wondering if on your unit(s) the value when no button is pressed is very close to the change over point to down button pressed and a litle bit of elecrical noise makes it look like the button is pressed every now and then.

Another possibility: In the code reading the analogue input, there are short delay loops. It may be that some devices need somewhat longer delays for the reading to work reliably.

I don't know if that makes sense hardware-wise, but I did get similar problems when a version of the compiler I tested optimized away the delay loop completely. However, it would explain the case when it only happens sometime, like during playback and during database build. In these cases, the CPU is boosted (at least periodically), making the delay loop shorter in time.

Should be easy enough to test: just make a build with a slightly longer delay loop (for the h100 series, the code in question is in firmware/target/coldfire/iriver/h100/adc-h100.c).

[DrSpud]

just make a build with a slightly longer delay loop (for the h100 series, the code in question is in firmware/target/coldfire/iriver/h100/adc-h100.c).

I can confirm that changing the 9 to 11 in the loop indeed stops the scrolling down problem. Whether boosting or not, ADC_BUTTONS shows mostly consistent readings when buttons are held down - though some still flicker a bit, but not by much.

[Erithacus]

With my H140, I've had exactly the same problem as reported by djhudson, except that the automatic scrolling occurred without any reference to the database, on all the menu screens.  This was using the standard daily build from 25 June 2007.  Curiously, I deleted it and installed Mmmm's recording enhancements build (r13711M-070625), and the problem did not exist.  Perhaps this may help identify when the problem began with the daily build?

[pabouk]

I had the same problem on my H120. It appeared after installing a build from the 28th June. I did not upgrade for more than a week before that. Now it seems that the problem is gone after installing a build from the 1st July. Both the builds were downloaded from build.rockbox.org. I think that the buggy build was compiled using a different GCC version. Unfortunately I do not have the information anymore. The working version I am running now was compiled using:

gcc: m68k-elf-gcc (GCC) 3.4.6
ld: GNU ld version 2.16.1
Host gcc: gcc (GCC) 4.1.2 (Gentoo 4.1.2)

See the attached rockbox-info.txt.

[attachment deleted by admin for age]

[pabouk]

Just a moment ago I downloaded the latest build r13758-070701 which is buggy again. It was compiled using

gcc: m68k-elf-gcc (GCC) 3.4.5
ld: GNU ld version 2.16
Host gcc: gcc (GCC) 4.0.2 (Debian 4.0.2-2)

It seems that either at least one of the build servers has a wrong gcc version for Coldfire targets or the code has a new part which is unexpectedly dependant on certain versions of gcc. By the way is it possible to identify the build server from the rockbox-info.txt? The file is attached.

It seems that the phantom down key-presses appear when Rockbock reads from the HDD or when the backligh fade out starts (this is the reason of the volume going down in periodically repeating steps) so it probably has something to do with interrupts or cooperation between threads.


[attachment deleted by admin for age]

[Llorean]

Bagder has told me he'll be disabling Coldfire builds on the 3.4.5 server until it's upgrade, so keep watchful and see if the problem goes away.