Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category FM Tuner
  • Assigned To No-one
  • Operating System All players
  • Severity Low
  • Priority Very Low
  • Reported Version Release 3.6
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by bertrik - 2010-11-02
Last edited by bertrik - 2010-11-05

FS#11714 - tea5767 tuner detection

Currently the TEA5767 tuner driver does not support detection of the presence of the tuner chip, it simply assumes that it’s always present. For some targets (HDD16x0 / HDD63x0 for example) this means that the radio can be “detected” even when not present.

This patch adds detection support for the tea5767. Detection is done by looking if there is an i2c device responding at all during initialisation and by checking the chipid field in the data read back from the tuner (should be 0).

If you have a target with a tea5767 tuner chip (see http://www.rockbox.org/wiki/FmTunerHardware#TEA5767), please try if the radio is still detected.

Closed by  bertrik
2010-11-05 17:05
Reason for closing:  Accepted
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

Variant of last patch committed as SVN r28493.

Updated patch:
* considers bit 0 to also be part of the chip id, the datasheet says this should always be 0
* pre-init the i2c read buffer with a 0xFF value so it will NOT be recognised as a tea5767 in case fmradio_i2c_read fails silently (it seems to do so on PP targets)

Hopefully this improves detection.

Tested and works on my GoGear HDD6330.

H100 still thinks it has a radio with the batch :)

It works now for the PP I2C target (Philips HDD6320). I suppose it’s because of considering bit 0 as a part of chip ID (readouts were 01 01 01 ‘01’ 2C or 02 02 02 ‘02’ 2C before).
Edit: Readouts are really random - fourth byte can be: 0×01, 0×02, 0xA7, 0xE7, but it is good enough.

Thanks all for testing! I think this can be committed soon.

Curiously, all read values being the same (as seen by Szymon in some cases) is one of the methods the linux tea5767 driver uses to exclude the presence of the tea5767.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing