dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Red led dead - this is where it goes wrong!!!

Red led dead - this is where it goes wrong!!!

From: Mike Holden <>
Date: Thu, 1 May 2003 11:07:10 +0100 (BST)

Ok, after a lot of debugging, and a __LOT__ of walking round and round the
block (the neighbours must think I'm potty!), I can give details of where
the unit locks up when we see the red led dead problem (at least for my FM
unit - I assume the recorder is the same problem). The way I did it was to
add some global variables to track variable values and code flow, and add
some new elements into the WPS to display these values. If anyone would be
interested in this, I can post a patch, but I warn you "it ain't pretty"!

Basically, when we hit this problem, the ATA_ALT_STATUS __always__ returns
0x80 (BUSY). This means that wait_for_bsy() loops for 10 seconds before
returning a timeout status. This usually happens when called from
perform_soft_reset() in ata_read_sectors(), and the structure of that
function is that it will loop 9 times waiting for wait_for_bsy() to return
ok (which it never does). We therefore spend 90 seconds looping around
perform_soft_reset() before returning an error which is passed back up to
the read() call in the mpeg thread. This then skips to the next track,
which fails and we go round again until eventually hitting the end of the
playlist (or directory).

I have tried changing the perform_soft_reset() call to an
ata_hard_reset(), but it seems that this doesn't always sort out the disk
either, so I need to look at an even more severe reset method.
ide_power_enable() is disabled on FM, but maybe calling this would work if
the functionality were added elsewhere (maybe create an
ata_VERY_hard_reset() !)

It also seems to me that the timeout in wait_for_bsy() and wait_for_rdy()
is way too long. Given that the maximum skip buffer is 7 seconds, surely a
shorter timeout than 10 seconds would be appropriate? In "normal" use, the
longest time that wait_for_bsy() takes to be ready is around 200 ticks
(0.2 seconds). Surely a timeout of something like 2 seconds would allow
the code to still work normally, without introducing undue delays when
problems occur.

My recommendations:
1. Change the perform_soft_reset() to ata_hard_reset() at the top of
2. Reduce the timeout in wait_for_bsy() and wait_for_rdy() to 2 seconds.

Neither of these measures will totally resolve RLD, but will at least
lessen the inconvenience.

In the meantime, I will continue trying to find the optimum reset method
to enable the unit to continue working.
Mike Holden
Received on 2003-05-01

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy