Rockbox

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

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.

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.

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?

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.

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.

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 :)

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.

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)

Attached is the fix I discussed earlier. I haven't seen any failures anymore (static just after boot).