Rockbox

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
==========
jonnyapple wrote:
Here's a workaround that worked for me and seems to be slightly less annoying than booting into the Sansa firmware when you want radio:
Set Settings>General Settings>System>Start Screen to 'FM Radio.'
The radio comes on every time you turn on the player, but then at least it's on the menu and stays there for me.
----------
enginerd wrote:
Only tried a couple of times but has worked so far.


UPDATE:
Well this morning it didnt work Sad

It went to the screen to start playing FM, but no sound checked the debug and No Hardware.

Well back to the OF


UPDATE 2:
After playing around with it for awhile i have noticed that FM is always present after the USB unplug system restart. Even if nothing is changed on the system... no new files no update nothing just unplug usb... system restart .... ta da FM
=======================

It seems like a compelling lead, anyway. Hope this helps. . .

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?