ok - let me take back that it's still an issue in today's build.. I need to test some more and then
either confirm or request that this bug report be closed.

I tested the other bug reports again before reporting that they're still an issue.. For some reason,
I forgot to test this one today and tested it afterwards.

It was definately in the official build the past few weeks.
Note, it doesn't consistantly disappear upon first database initialization. I have yet to find a pattern.

ok - after another couple of DB refreshes and reboots, the FM Radio menu is gone again.
Again, I'm not really sure what's triggering this issue.

So:
Still an issue August 1, 2007: r14133-070801 is true!

Mine done it yesterday after some Themes tryout, it disapeared and needed to reinstall RockBox.

Just tried this on my dads sansa (mine doesnt have radio), and couldnt reproduce it..
when it disappears, does the fm debug screen show the radio hardware?

That's weird because once the radio is detected the first time, the "present" flag should be permanently set for the session.

When it disappears, it is listed as hardware not available, in the debug radio hardware screen.
Over time, the radio just comes and goes, even with the same build, without reinstallation. (I do have auto database initialization, and I
add new files every day, so if it does have
anything to do with that, that could be why mine comes and goes)

sonus more like a dodgey hardware connection than anything else…

Not, to me. it sounds like a bug. In working with threading something came up that makes me suspect hidden stack overflows. I haven't yet checked if shutting down the database affects this (it was on with auto update). Way off topic to describe in detail here but stack usage was found on a stack that shouldn't have yet been used at all. One key thing I want straight here is: does the radio present status ever change within the same rockbox session or only after a restart? I also haven't determined if that really matters to this bug but I think database would be most demanding of stack while updating something.

Yah, I"m not sure when the present status changes… at this point it's on again off again and I don't use the radio much… I never remember what I did or didn't do prior to the status change.

There are a number of us on the Anything But Ipod forum who have the same issue. It started a few months ago already.

I have a Sandisk Sansa e250 and this is occurring with me also every the database is updated.

is this still occuring?

Yes. Usually when i add files and the database is reloaded.

I thought I'd add that I didn't have Auto-Update enabled, and FM Radio just totally disappeared on my Sansa e250 as well after the first boot. It could have been that I initialized and updated the Database manually, but it won't come back. On my device, it's not that auto-update is causing problems. Mine has never been turned on.

Is it possible that the original firmware version could have anything to do with this? It seems odd to me that duplicate hardware with duplicate versions of Rockbox could be producing different outcomes. I have never experienced this bug on my e200 using v1.02.18A.

Well, we could post the OF versions we're using.

I am using OF version 01.02.18J

I guess this has probably been tried, but what about setting FM_CLK_DELAY to 2?

I have no idea how to set that FM_CLK_DELAY thing. I'm assuming it's a line in the source.

I am now using OF version 01.02.18A on my e250, and it's still doing the same thing. After screwing around with trying to get newer versions of the firmware installed, reinstalling the bootloader, etc, I was able to see the FM Radio option on the main menu. When I rebooted, the option was gone.

As of right now, I still have to boot into the OF to get Radio. It's workable, but not optimal. Is there anything else I can provide to the knowledgeable people on this task? I can take my device apart….give model numbers, serial numbers, printed chip designations… lol. I'm not much of a programmer, but I can provide any information I have.

Just a quick bump to remind people that this is still occurring. FM Tuner is available when I first install it, but when I turn it off and back on again, the Tuner is gone, and never comes back, from what I can tell.

Is there any further information I can provide to help anyone?

Someone posted some information on the forums that may be helpful for this issue. It looks like he never got around to posting it here. . .

http://forums.rockbox.org/index.php?topic=16538.15

I just noticed that Marc changed this to "Due in version 3.0". What does this mean? There's a fix, and it'll be implemented in version3?

I can confirm that the FM Radio DOES return after I unplug from USB and the OF restarts into Rockbox. Power cycle again, and POOF, FM Radio is gone again.

Chris, "Due in version 3.0" simply means that this is something that should either be fixed by the time of a release or documented as a known bug of importance.

I looked a bit through the radio code, especially the startup/detection sequence. The sequence is as follows:
* function radio_hardware_present eventually calls lv24020lp_get(RADIO_PRESENT)
* this calls tuner_power(true) which does some target-specific initialisation, which then calls lv24020lp_power(true)
* lpv24020lp_power reads the chip identification register once, makes a decision based on this value and caches the result for further calls

Here's my review for possible problems:
1) the tuner_power function for sansa c200/e200 has a comment about a "mystery amplification device". I think this needs clarification, is it really for amplification or does it control some kind of power switch to turn on the radio chip?
2) in case the mystery amplification device is actually something to turn the power to the radio chip on or off, the following udelay of 5 microseconds seems a bit short.
3) for e200, only GPO32_ENABLE is configured, which I interpret as configuring a specific pin as GPIO, but not defining the pin's direction or value yet. Wouldn't we also need to set the GPIO direction and output value?
4) the chip's datasheet mentions a minimum timing of 0.75 us for most parameters and the currently used delay of 1 us seems safe, but I think udelay(1) may actually provide a delay that can be shorter than that. The udelay function is based on a microsecond counter in the PP50xx and is defined in system-target.h. The current implementation of udelay(1) delays execution until the microsecond counter has changed from x to x+1 (or higher). So when the microsecond counter is just about to increase from x to x+1, the resulting delay may be considerably shorter than 1 microsecond. There will be some overhead from the code that makes the delays a bit longer again, but it's not guaranteed.
5) is the proper register block selected when reading the chip identification register? It looks like it does, but it's not immediately obvious.

I think FM_CLK_DELAY should at least be increased from 1 to 2.

To properly tackle this problem, I think we first need a good reproduction recipe. We could for example reduce the udelay(5) after "mystery amplification device" to see if it increases the likelihood of the bug (or even if it results in the same kind of bug at all). Maybe timing can be influenced by temperature like cooling it in a freezer (probably avoid freezing the battery) to see if it gets better or worse. We could also show the chip identification value in the debug menu (e.g. to see if it's completely wrong or just slightly wrong).

After looking a bit closer, most issues seem quite harmless:
1) I tried disabling the mystery amplification device on my c200 and it just disables sound from the radio, the radio itself is still detected. So it's not a kind of power-switch to the radio chip itself.
2) Removed the 5 microsecond udelay and it didn't seem to affect radio detection.
3) As the name suggests, GPO is for general-purpose _output_ pins, so the direction probably does not need to be set. The pin output value is already set to low in system-pp502x.c (function system_init).
4) udelay(1) is still a suspect, although 750 ns is not such a long time (just 18 ticks at 24 MHz)
5) I think this works as expected too (properly switching the register block to 1 before reading the chip id registers, since it boots up with register block initialised to 0).

umm, i think its *GPIO* not GPO, which means the direction would have to be set, right?

according to  FS#9839  this is still valid.

My Sansa e260 still exhibits this behavior, even with RB v3.2. Can't count on the FM Radio unless I'm in the OF. So… bump.

I just purchased a Sansa e250 for a gift with the same issue - FM Radio isn't available in the menu unless you boot from a USB unplug or from the original firmware. In the original firmware the FM radio always works. This is specific to the Rockbox firmware only. Original firmware version is 01.02.18A. I am using Rockbox version 3.3. For comparison I own a Sansa e260 running original firmware 01.02.24A on the same Rockbox install version 3.3 without any issues. I purchased the e260 in 4/2008 and have run Rockbox on it since version 3.1.

Just to eliminate one more possibility that the newer original firmware (O/F) had modified someother internal IC code I flashed the e250 to the same O/F version as the e260 (01.01.24A). No difference (I was 99.9% sure there wouldn't be). As a Test Engineer I believe Bertrik is on the right track. This has all of the indications of a timing issue. If the FM hardware is detected at bootup it works for the rest of the session. It's detection is very sporadic in Rockbox. It appears to be right on the edge of a hardware ready to detect phase. Perhaps a conditional do_while loop could delay (x) period of time and recheck the hardware presence for (x) attempts before proceeding. Let me know if I can help in field testing this issue. I am supposed to present the gift on 8/1/2009. It would be nice to resolve it before then.

I'm pretty sure the e200v1 radio problems have been sorted out. Does anyone actually have this problem still?

I just installed Rockbox Version: 3.11.2 on my e250 and the problem is still there pretty much the way it was four years ago. Where does your optimism come from saratoga? Has there been progress not reported here?

  I get the FM Radio when I boot by unplugging the USB.  I can also get it by forcing the original firmware (with the |<< key) and then powering off and on--quickly.  This brings up Rockbox with the FM Radio.  It's like, if the FM chip is still "warm" ("charged up"?) Rockbox sees it but if it's "cold" Rockbox gives up too early and declares it dead.  

Agreeing with StogieB. Just fresh installed Rockbox on an old v1 c250 with FM radio, empty database with no music. FM radio did not show up at all until I booted into the firmware, activated the radio, then quickly rebooted into Rockbox. It's showing up now, but we'll see for how long.