Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Notice: A non well formed numeric value encountered in /sites/ on line 96 Deprecated: Function create_function() is deprecated in /sites/ on line 104 Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /sites/ on line 845 Deprecated: Function create_function() is deprecated in /sites/ on line 111 FS#10474 : FM tuner on Gigabeat S fails to tune last frequency on start



FS#10474 - FM tuner on Gigabeat S fails to tune last frequency on start

Attached to Project: Rockbox
Opened by Eric Jorgensen (EricJorgensen) - Thursday, 30 July 2009, 00:02 GMT
Last edited by Bertrik Sikken (bertrik) - Monday, 21 June 2010, 16:45 GMT
Task Type Bugs
Category FM Tuner
Status Closed
Assigned To No-one
Operating System Gigabeat S
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


in r22084 and some previous versions (I know I've noticed it before) the FM tuner is not tuned when the tuner function is launched.

The frequency is remembered from the last time the fm tuner was used, but only static is heard until i seek in either direction and back to the frequency.

This behavior on the Gigabeat S differs from the way the fm tuner behaves on other targets.
This task depends upon

Closed by  Bertrik Sikken (bertrik)
Monday, 21 June 2010, 16:45 GMT
Reason for closing:  Fixed
Additional comments about closing:  Should be fixed in SVN r27018
Comment by Eric Jorgensen (EricJorgensen) - Thursday, 30 July 2009, 00:45 GMT
I forgot to say, this occurs only on cold boot - if the beast has been turned off since the last time the tuner was used
Comment by Bertrik Sikken (bertrik) - Thursday, 30 July 2009, 06:57 GMT
Actually, this happens on the ams sansas too (which use the si4700 fm tuner too). I've seen it on my clip. When it happened, the FM debug screen showed that register 0x03 had been written with the correct value (channel index), but somehow the channel readback register 0x0B still showed 0. This means that the correct frequency had indeed been written to the fm tuner chip, but somehow it has not tuned to it.

A tuner bug from the AMS sansa that may also exist on the gigabeat S is that the player hangs when accessing the radio when it is powered off (e.g. paused). Could you try the following and see if it has the same behaviour as on the Clip? : go to the radio screen, pause, then skip channels -> hang.
Comment by Eric Jorgensen (EricJorgensen) - Thursday, 30 July 2009, 16:26 GMT
Yes, i get the same hang on my S60 when i pause and then skip.

Also interesting - the last two times i turned on my S60 and went into the fm radio function, it started up tuned - so it would appear to be intermittent behavior.
Comment by Michael Sevakis (MikeS) - Monday, 03 August 2009, 19:25 GMT
Hmmm...I can't get my S30 to do this at all after about a dozen times of trying. :-\

But, for the hang. Yes. Perhaps the tuner shouldn't be placed in standby during pause but instead just muted. I'm not really surprised there. It's not a hard lock as there is still backlight action. So, is the loop to wait for tuning not exiting?
Comment by Eric Jorgensen (EricJorgensen) - Monday, 03 August 2009, 19:43 GMT
I caught my gigabeat doing this three times in a row and then posted the bug report.

I can't get it to do it now.
Comment by Bertrik Sikken (bertrik) - Monday, 03 August 2009, 20:14 GMT
I can quite easily reproduce this on my clip but can't see a pattern yet. My clip has a device id of 0x1242 and a chip id of 0x1053. When it happened the READCHAN register was 0 while the CHANNEL register was set. If I look at the code, this means that somehow the driver thought tuning was complete because the STC bit was set. Maybe we should add a check here on READCHAN being equal to CHANNEL (I vaguely remember discussing this earlier or seeing it in the OF), I can't find a requirement for this in the datasheet though. The STC bit is also used during seeking, maybe this is interfering.
Comment by Michael Sevakis (MikeS) - Tuesday, 04 August 2009, 21:05 GMT
I haven't updated my RB on the S for awhile (r20571 - 090330) so maybe something crept in since then? The S goes through precisely the same interface selection procedure as the OF (which is also the same as the DS) when initializing the FM chip though I'm not sure it matters here. At least it being on both types of devices basically rules out a SoC-specific issue.

The need for a tuning check might be an errata of sorts not covered in the docs we have?

Seeking as currently implemented is just tuning and then checking a level and so not fundamentally different. I can't see where that would matter. Perhaps it doesn't reset the bit fast enough before the tuning sequence is initiated. Maybe check if a delay matters...say, one tick? (some guesses, no code in front of me atm :)
Comment by Michael Sevakis (MikeS) - Monday, 24 May 2010, 21:15 GMT
I just fixed the hang problem while paused. I also tried using FM as the startup screen and got a blast of noise in my left ear for a fraction of a second. It could be trying to start the tuner before the aync audio hardware init is finished (guess). It did tune and go to normal volume however.
Comment by Bertrik Sikken (bertrik) - Thursday, 17 June 2010, 14:54 GMT
I looked at si4700 tuning code recently (for the Sansa Clip+) and it seems to indeed check both the STC bit (seek/tune complete) _and_ compare READCHAN (actually tuned channel) with CHAN (desired channel). If not satisfied, the TUNE bit is taken down and the tune is tried again (a few times) until it does tune. This should fix it. I hope to post a patch soon (sometime in the next 7 days)
Comment by Bertrik Sikken (bertrik) - Sunday, 20 June 2010, 17:06 GMT
Attached is the fix I discussed earlier. I haven't seen any failures anymore (static just after boot).