Rockbox General > Rockbox General Discussion
iRiver H120 button problem
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:
--- Quote from: Multiplex on June 28, 2007, 08:47:57 AM ---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.
--- End quote ---
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).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version