Author Topic: Programming off the shelf CSR8635 module  (Read 170310 times)

0 Members and 1 Guest are viewing this topic.

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1610
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #25 on: June 05, 2016, 12:12:45 am »
The 1.8V is *usually* broken out on the module on a pin.  Would trust to to supply much, but should be fine for the FT232. 

Yes, I used that as the VCCIO on my FT232, as well as 220ohm series resistors 'just in case'.

As for range, RF is always tricky, and you may have noticed that many cheap modules china kicks out, whilst functional, and sometimes very useful - rarely design good PCB antenna's.  Often these are just copied from gerbers of other designs - many inverted F, meander, PCB antennas in general etc.. are copied without any care about what matching network to use, or the effect of housing, nearby traces etc..

It seems most bluetooth 'audio' modules (ones mounted on a PCB with audio amps, regulators and connectors) just have a bare wore soldered to the antenna, then to the PCB so one can 'connect their own'.  But this not only detunes the antenna, it also provides an unknown impedance out.  Connect it to a 50 ohm antenna and who knows what range you'll get, its all very haphazard.

I've used the cheap blue CSR8645 modules mounted on a  PCB with the antenna off the edge - away from traces, inside a plastic housing and had no trouble with 8m.

There are PSKeys to set the tx power, but it can only set the 'max' and the actual power it uses is dynamic - it will change tx power on the fly to save battery life when the link is robust.  A reasonable way of making it easier to get 'good range' would be disconnecting the PCB antenna (there's a 0402 cap that acts as a link between the onboard antenna and the module pin) and using 50-ohm coax to an RP-SMA connector, then a standard 2.4Ghz 1/4 wave antenna, the likes of which you get on wificards.  This of course would hinder portability, but if its going in an enclosure - especially a protable speaker, then an external antenna would allow you to use a metal housing, as well as provide a fairly decent range.

For audio streaming the range is inherently limited by the high throughput and limited time for resends
 
The following users thanked this post: l0rd_hex, smolny

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #26 on: June 19, 2016, 07:59:10 pm »
I bought an amplifier board too, it ("BLAMP-50W-V3", http://www.ebay.com/itm/281967072104 ) is built around the TDA7492 50W class-D amplifier and a CSR8635 bluetooth module (without antenna). The main board is populated with a a DC socket for power (center positive). Pairing went without problems ("M-DIY-AUDIO-"). At 12 V it draws less than 100 mA with "JBL Control One" (~10 yrs old), and I don't need it much louder. The AUX input (3.5 mm stereo) has a contact to detect if something is plugged in and it seems to be routed via the nearby SGM4717 analog switch. Volume control is digitally controlled via pushbuttons and I suspect that everything goes through the bluetooth module. Unfortunately, there is quite a bit of quiescent noise. It's tolerable at room level but not suitable if you want to listen to something very quietly (e.g at night). Dialling down the amplifier gain level via DIP switches helps a bit, also making the source louder and the module quieter seems to help a bit.
Actual problems however are the default volume level and the startup sounds. Powering the board, one is greeted with a loud "du du du da - blip" followed by aforementioned audible white noise. It takes 6 "volume -" button pushes to get that down to bearable. So I am trying to figure out how to change that.

I seem to have found the pinout of the module in question, "F-3288":
  http://www.aliexpress.com/item/New-Arrival-Bluetooth-4-0-Stereo-Audio-Module-Control-Chip-CSR8635-Stereo-Bluetooth-Module/32308035803.html
  http://www.dhgate.com/product/bluetooth-stereo-audio-module-ble-4-0-module/241472833.html

Trying to figure out the audio signal paths:

MIC -> C82 -> SGM4717  Pin 2 NO1
GND -> C86 -> SGM4717  Pin 5 NC1
SGM4717 Pin 3 COM1 -> BT-Module Pin 27 LINE / MIC_AN

MIC -> C87 -> SGM4717  Pin 10 NO2
TRS Audio jack Tip (left channel) -> C81 -> SGM4717  Pin 7 NC2
SGM4717 Pin 9 COM2 -> BT-Module Pin 28 LINE / MIC_AP

TRS Audio jack Ring (right channel) ->  C80 -> BT-Module Pin 31 LINE_BP
TRS Audio jack Sleeve (GND) switch contact ->  BT-Module Pin 19 RX (PIO0/PIO1?*)
BT-Module Pin 30 LINE_BN -> C88 -> GND

BT-Module Pin 18 TX (PIO0/PIO1?*) -> SGM4717  IN1&2   

*note that the schematics differ from pinout

So the analog switch normally routes the audio jack to the IC's Line in pins, but the IC detects if no plug is present and then has the choice of using the microphone as input (for the bluetooth hands free function). So the audio is ADC/DSP/DAC'ed and I think that might not help with the noise.
So I am thinking about bypassing/mixing the jack input directly to the amp input, which should be accessible at the filter capacitors next to the BT-Module outputs. However, to be able to use the Bluetooth audio as well, I need to at least change its startup volume and sound. So ...

The BT-Module has 4 undocumented pads on top, near the GT4128 "2-WIRE 128 K Bits Serial EEPROM" (http://www.giantec-semi.com/upload/datasheet/GT24C128_DS_Adv.pdf) :

1 (module corner) EEPROM Pin 7 WP - CSR Pin  PIO12 Pin 22 (SPI flash chip select)
2 CSR8635 Pin 31 - PIO13 (SPI flash data bit 1)
3 VCC / 1V8
4 GND / GND

What could this be used for?

Found the datasheet:
http://www.datasheetcafe.com/csr8635-datasheet-csr/ -> http://www.ndatasheet.com/datasheet-frame/300/mdownload.php?id=869877

EEPROM connections (see pads above)
1-4 GND
5 SDA <-> CSR Pin  PIO11 Pin 26 (SPI flash data bit 0)
6 SCL <- CSR Pin  PIO10 Pin 25 (SPI flash clock)
7 WP <- CSR Pin  PIO12 Pin 22 (SPI flash chip select)
8 VCC (1.8 V, up to 5.5 V for GT4128 only!)

So reading this directly is not out of the question but the work is probably the same.
This leaves digging out an unreliable FT232RL board I made years ago...

On this module, PCM needs to be pulled high to enable the debug SPI interface (and I think released again, to test the new settings).

So far I have been able to change the device name but my changes have always caused problems (and suspected bricking, but then after a few trials, reading/writing was possible again) . At the moment, I cannot connect to the device at all; the programs just freeze at "communicating with device". Buriedcode might be right. I think the last I tried was "Merging" a ConfigTool .psr file into the connected device in PSTool... Maybe my FT232RL wires are falling apart.

I have written a small Python script that reformats the ConfigTool .psr into something more similar to what PSTool generates. Makes it much easier to compare. Will publish that soon.
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #27 on: June 22, 2016, 09:57:44 am »
Despite rebuilding my FT232 interface with SOP-adapter and a breadboard, triple-checking all voltages (VCCIO), I am not able to program the chip anymore. I can only read the firmware ID with Blueflash. PSTool and ConfigTool transfer data indefinitely. After a few seconds of "opening transport" or whatever, the data rate is changed drastically and then it just keeps on communicating. I once managed to "cancel" during the initial phase and PSTool actually showed its list of keys. Writing my backup dump failed.
The command line tool used with usbspi.dll's debug-options (https://github.com/lorf/csr-spi-ftdi) does the indefinite transfer with a lot less CPU usage and only ocasionally reports SPI errors. So it does not seem a problem with transport, but rather the communication.
PSTool and Blueflash seem to work only in their installation directory, otherwise PSTool simply does not start. Blueflash seems erratic in finding the adapter. I previously used 2.6.2 but reinstalled 2.6.0 to be sure.
When things hang and the processes are killed, the SPI levels are left 'dangling', i.e. CS# is not released. So replugging the FT232 is necessary.
I am not certain whether writing bad keys could have corrupted the chip (ROM). It could be that the interface voltage was too high at some point. Also, I have to admit I did not use resistors. So maybe I fried the chip.
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1610
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #28 on: June 22, 2016, 10:21:40 am »
What IO voltage were you using for the FT232?  I would have thought it could cope wtih 3.3V if series resistors were used, but I have used the 1.8V from the module as VCCIO on the FT232.  I too initially had problems with infinite 'reading....' but that turned out to be the shoddy breadboard setup.  Once I made a semi permanent version on stripboard it worked like a charm.  I had a 10K pull up on the CS line as well because the FT232 can make its IO's high-Z.

If you have bricked the module, I can send a *.psr file to you to at least get it 'back to default'.
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #29 on: June 23, 2016, 11:49:09 am »
Thanks for the offer, greatly appreciated! I'm not sure if my dump may be corrupted, as I've only made it after playing with ConfigTool. However, I used to be able to restore it at the beginning, which I now cannot (can't read or write, only read firmware). I used the 1.8 V output from the module for VCCIO, but this was pulled higher for some reason, and once it disconnects I am not sure what the FTDI actually puts on the CSR inputs.

I did lower the SPI clock down to 20 kHz, to no avail. However, the signals look OK. I might attempt a capture by logic analyzer and see if there are decode errors.
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1610
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #30 on: June 23, 2016, 02:51:41 pm »
These chips are easily bricked by the 'CSR-tool' as it only writes specific keys- and wiping the rest.  It can mean the chip gets stuck in a bootloop because whilst the firmware is in ROM, the on-board I2C EEPROM contains configuration for booting as well as user config.  It took me a few days of head-scratching and I actually had to order a second module to read the keys off (with PStool) and write them to the bricked module (also using PStools). 

The result of the shoddy config was - very slow reading with PStools, and then it froze.  I cannot remember exactly how I managed to stop this but I believe it was playing around with the Vreg line (Vreg enable, also the 'multi-function button' input).  I was also using a separate power supply for the module - not derived from USB - because the FT232 would take a while to power up, and the CSR module I had used a POR circuit (holds reset line low for ~3ms at power on) it would power up sometimes before, sometimes after the FT232.  That way I could connect to the dongle using PStools, then power cycle the CSR module, then try to 'read from device'.

The only way I found to modify the settings using CSR_headset_config was to get a dump using PStools.  Then read the device with the headset config utility, make modifications but write to a file.  Then you have your original config, and the config form the headset utility that will only contain a few PSkeys.  Using notepad ++ with the compare plugin, I could see what the headset utility had changed, and copied them over to the original dump.  This was then written back to the device.  Its long winded but it works.
« Last Edit: June 23, 2016, 02:59:36 pm by Buriedcode »
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #31 on: June 25, 2016, 06:31:12 am »
Something is definitely stuck in a loop, I'm just not sure whether the CSR or the PC side has the problem.

This is four repetitions of the MISO line data:
Code: [Select]
0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

And MOSI repeats, too:
Code: [Select]
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00
0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00

This sequence can be found in both:
Code: [Select]
0x00 0x00 0x30 0x06 0x00 0x00 0x04 0xB0 0x00 0x00 0x00 0x80 0x00 0x00

The chip reports stack version 8648 (0x21c8):
  "dal_10compact_rom_bt4.0_dal_a04_1112061248_encr128 2011-12-06"

I might try to send a "debug,dump" log to the csr-spi-ftdi developer in the hopes they might be able to see what's being sent.
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #32 on: June 25, 2016, 06:33:53 am »
Here's my little Python script

Code: [Select]
#! python
#coding=utf-8
"""Convert .psr files as generated by CSR ConfigTool into the format that BlueFlash 2.6.2 uses.

Strips the header, reformats comments, omits empty keys and strips blank lines.
Writes keys in ascending order to stdout. Usage: pipe into new file like "psr.py infile > outfile".
"""
# settings
comments = True
reformat = True
empty_lines = True
showheader = True

import sys

def main(filename):
    """"""
    # read the whole file and split it into list on empty lines, ignoring the file header
    with open(filename, 'r') as f:
        r = f.read().strip().split('\n\n')
        header = r[0]
        keys = r[1:]

    # iterate over comment/key line pairs
    d = {}
    for key in keys:
        # split the pair
        comment, key = key.split('\n')

        # reformat comment
        if comments and reformat:
            parts = comment[2:].split('-')
            pskey = "".join( parts[0].strip().split() )
            if not pskey.startswith("PSKEY"):
                newcomment = "// PSKEY_" + pskey
                #comment += ' (' + parts[1].strip() + ')'
            else:
                newcomment = "// " + pskey
        else:
            newcomment = comment

        # test for data
        try:
            # key has data
            address, data = key.lower().split('=')
            d[address.strip()] = (data.strip(), newcomment)

        except ValueError:
            # key without data
            print("skipping key (no value):", address, comment, file=sys.stderr )
            pass

    # output
    if showheader:
        print(header)
        print("##        converted by psr.py        ##")
        print("#######################################")
        print()

    for key in sorted(d):
        if comments:
            print( d[key][1] )
        print( key, "=", d[key][0])
        if empty_lines:
            print()

    print("Done. Key(s) reformatted:", len(d), file=sys.stderr )

if __name__ == "__main__":
    main( sys.argv[1] )

I wonder what the CSR does if it cannot find the EEPROM?
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #33 on: June 25, 2016, 08:12:52 am »
I found hints on writing to / clearing the EEPROM with BlueSuite'S e2cmd.exe when searching for info on a CSR site. It's also mentioned in https://github.com/lorf/csr-spi-ftdi#useful-commands. After successfully (!) doing

Code: [Select]
set SPIMAXCLOCK=20
set FTDI_DEBUG_LEVEL=debug,dump
set FTDI_LOG_FILE=log.txt
e2cmd.exe dump eeprom-backup.hex
e2cmd.exe fill 0xff

I was finally able to connect with PSTool again and restore my backup PS keys.

But "rebooting" the module without the debug SPI enabled, it does not show the original behaviour and it does not show up in the ether either.

So I think I would need the original EEPROM contents that probably also contain the code that manages the audio switching on my amplifier board. If someone has this board or one that uses the signals described above, could you send me an EEPROM dump please?
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #34 on: June 25, 2016, 08:24:47 am »
On second thoughts, I'd appreciaty any working EEPROM contents for this chip in order to try to get it to work again (as long as I can connect and it DACs some audio it is useful to start with).
 

Offline BananaForScale

  • Newbie
  • Posts: 1
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #35 on: June 26, 2016, 10:15:42 pm »
Also interested in programming the module on an amplifier board, would the babel programmer work (http://www.digikey.co.uk/product-search/en?keywords=DK-USB-SPI-10225-1A-ND%09 , http://bcdmicro.co.uk/shop.php?pg=4#!/CSR-Low-Cost-Babel-USB-SPI-Debug-Programmer/p/50636001/category=11287798 ) or the one mentioned before in the thread. I have got CSR Blue Suite 2.5.0 but not a programmer yet (don't know what one) and I can't find good information as most is in Chinese.
Thanks 
 

Offline doctormord

  • Regular Contributor
  • *
  • Posts: 190
  • Country: cx
  • !nop
    • #fine_arts & #electronics - 360customs.de
Re: Programming off the shelf CSR8635 module
« Reply #36 on: June 29, 2016, 04:57:20 pm »
(Bulk) Writing to the device or unbricking it is much more reliable if you disable the VM first via PSTools and the corresponding key.

It's named "VM disable". After setting this "true" restart the module from within the tool.

After writing back your dump, just enable it again if it's not by itself after power-cycling.

Another note:

If you change settings with the ROm configure tool and write the keys back to your device it will brick the FW keys for the enabled codecs. (AAC,MP3,APT-X - so only basic A2DP and SBC is left then)

Diffing the dump to your settings is easier if you first load your unchanged dump, made with PS-Keys tool, into the ROM configure tool and save it unchanged to a new .psr file as the keys gets resorted somewhat.
#fine_arts & #electronics  - www.360customs.de
 

Offline Limoster

  • Newbie
  • Posts: 1
  • Country: es
Re: Programming off the shelf CSR8635 module
« Reply #37 on: August 11, 2016, 07:00:16 am »
Will anyone help me find the pinout of this CSR8645? It looks a bit wider than most modules...

http://www.aliexpress.com/store/product/Free-shipping-Original-new-CSR8645-APT-X-Bluetooth-4-0-Audio-Receiver-Board-Wireless-Stereo-Music/1905399_32582365030.html

I found somewhere you can use a different method to change the name of the bluetooth module by hooking up a SOIC8 EEPROM Programmer to the EEPROM in the bluetooth module. It is more difficult because everything is in hex and most things are unreadable.
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1610
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #38 on: August 14, 2016, 01:16:31 am »
That method is essentially what using PSYkeys and the headset config utility does - just reprograms the EEPROM on the module.  It still contains config keys that we pretty much have no home of fully decoding so you'll need a 'stock' module with working config in its EEPROM to copy.  The main SOC is ROM-based - nothing to program there - that has capabilities fixed.

So ultimately, its actually more work to program an EEPROM, and switch it for the one on board.
 

Offline kile

  • Contributor
  • Posts: 18
  • Country: hu
Re: Programming off the shelf CSR8635 module
« Reply #39 on: September 06, 2016, 10:44:44 am »
I am trying to build a BT speaker with one of these CSR modules. This is my module: http://www.ebay.com/itm/CSR8645-Bluetooth-stereo-audio-module-support-APT-lossless-speaker-amplifier-AMP-/181903054267?hash=item2a5a4455bb:g:ZVoAAOSwYHxWHq-x

I've made a PCB that contains the CSR8645 module, the LEDs, buttons, power, USB charger and the flashing interface.

I have built a dedicated programmer based on the schematic found here: https://github.com/lorf/csr-spi-ftdi

The module works fine when powered. I can connect to it from my phone.

The problem is that the flash interface does not work. I can't even identify the module. This is what I get:

Quote
C:\>BlueFlashCmd.exe -identify
blueflashcmd, version 2.3.0.15
Copyright (C) 2002-2010, Cambridge Silicon Radio Ltd.
10:14:56.301658: all:spi.c:558:spi_init: csr-spi-ftdi 0.5.1, git rev b60665a
Resetting XAP
10:14:56.677089: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:14:56.761056: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:14:57.015927: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:14:58.995330: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:01.063303: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:01.200860: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:02.861680: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:03.175285: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:03.862987: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:05.192672: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:05.550446: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:05.804504: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:06.415120: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:06.649859: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:06.705838: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:07.273037: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:07.561272: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:07.877662: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:09.086594: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:09.095746: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
10:15:09.104089: err:basics.cpp:479:spifns_sequence_read: Unable to start read (invalid control data)
...

And this goes on forever or until I press Ctrl-Break.

This is the schematic of the PCB with the module (PDF):

https://drive.google.com/open?id=0B5QsMM8GX6NEWGk1b1QtbTRpLWc

I have not populated the USB charging part of the circuit. So, R7, R8, C2, Q1 and the USB plug are not on the PCB. I am powering the module from a Li-Ion 18650 battery.

This is my programmer (PDF):

https://drive.google.com/open?id=0B5QsMM8GX6NEdmxZNU5nVkg0dEE

The JP1 voltage selector is in the 1.8V position. The FTDI chip is FT232RL 1147-C. I have read that revisions A and C have bugs in the bit-banging modes of the chip, so maybe this is my problem?

This is a photo of the two PCBs:

https://drive.google.com/open?id=0B5QsMM8GX6NETzUwcG4zOTg0Nms

Before I did this I have already tried to flash a CSR8635 module (not CSR8645 like the one I have now) with a FTDI breakout and got the same result. I thought I messed up something with the wiring and I didn't have a stable 1.8V source for the FTDI, so I decided to make a dedicated programmer and a decent PCB for the BT module. But the result is the same, so I am guessing that something is wrong with my understanding of how this thing should be wired. Maybe I missed a pull-up or pull-down somewhere, or something like that.  |O

Any help or suggestion is more than welcome. Thank you!
 

Offline Dimoza

  • Newbie
  • Posts: 1
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #40 on: September 16, 2016, 03:13:29 pm »
Hi everyone,

a bit off-topic question (but i see that this is only thread, where people discuss CSR8635 module). So...
Am I right understand that this module can work in RX (default) as well as TX mode? If my assumption correct, how to switch module in TX mode? and how to initiate pairing process (for both RX and TX)? 

Thanks for any hints!
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #41 on: October 01, 2016, 08:32:18 am »
Maybe I missed a pull-up or pull-down somewhere, or something like that.
Do you have debug SPI interface enabled by pulling CS (SPI) high?
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #42 on: October 01, 2016, 12:42:40 pm »
I bought a 2nd unit to fix the first I bricked.
Testing dumping the bricked EEPROM with e2cmd.exe:
  128 kbit = 16 kByte part is installed
  only 8192 lines in hexdump, but these are word (0x00ff)!
  adresses @0000 .. @003ffe (16382) confirm

Which makes me wonder if my "fill" from june 25 was incorrect.

Code: [Select]
>e2cmd.exe fill 0xffff
e2cmd.exe, version 2.6.2.632 Release
Copyright Cambridge Silicon Radio Limited 2007 - 2015.

Fill successful

>e2cmd.exe dump eeprom-backup8kffff.hex
e2cmd.exe, version 2.6.2.632 Release
Copyright Cambridge Silicon Radio Limited 2007 - 2015.

File written successfully

Resulting in

Code: [Select]
@000000 ffff
@000002 ffff
@000004 ffff
@000006 ffff
@000008 ffff
...
@003ffa ffff
@003ffc ffff
@003ffe ffff

(nothing happens on reboot in run mode)

After writing default header with "e2cmd.exe header":

Code: [Select]
diff --git a/eeprom-backup8kffff.hex b/eeprom-backup_header.hex
index a3ec3ca..3918e34 100644
--- a/eeprom-backup8kffff.hex
+++ b/eeprom-backup_header.hex
@@ -1,13 +1,13 @@
-@000000 ffff
-@000002 ffff
-@000004 ffff
+@000000 8f70^M
+@000002 8f70^M
+@000004 0000^M
 @000006 ffff
-@000008 ffff
+@000008 0000^M
 @00000a ffff
-@00000c ffff
-@00000e ffff
-@000010 ffff
-@000012 ffff
+@00000c 0000^M
+@00000e 0000^M
+@000010 0000^M
+@000012 c0de^M
 @000014 ffff
 @000016 ffff
 @000018 ffff
@@ -4097,10 +4097,10 @@
 @002000 ffff
 @002002 ffff
 @002004 ffff
-@002006 ffff
-@002008 ffff
-@00200a ffff
-@00200c ffff
+@002006 0000^M
+@002008 0000^M
+@00200a 0000^M
+@00200c c0de^M
 @00200e ffff
 @002010 ffff
 @002012 ffff

(nothing happens on reboot in run mode)

PS Tool connects without problems
Factory>Factory Restore all
Too quick (nothing really seems to happen) and no effect (eeprom dump identical).

But "Merging" with the earliest PSTool "Dump".psr I could find results in ... the module working again (blue leds alternating, startup sound rising "du du du da". And I can connect again to "M-DIY-AUDIO-" and play music!

If you have linux tools available, this may help with comparing files:
Code: [Select]
grep "&" in.psr | sort > out.psr
But unfortunately, I have not been able to get the module to work with changed default volume levels yet

The interesting key is "USR 15 - PSKEY_FEATURE_BLOCK":
Code: [Select]
working (both levels 15):            &0299 = 9231 2c00 11e7 05f1 3e40 f61a
default AD2P volume level -> HFP 1:  &0299 = 9231 2C00 11E7 05F1 3E40 161A
default      volume level -> HFP 1:  &0299 = 9231 2C00 11E7 0511 3E40 F61A
aptx                                 &0299 = 9231 2C00 11E7 05F1 3E40 F71A
                                                              X       X
                                                                       X

Changing either of these in PSTool (filter for "15") breaks audio.
So it's not configtool's fault.

If you've had any success with these audio settings, please let me know.

Removing power-on sound (PSKEY_USR26)
This is what config tool does when one removes a sound (selecting no-sound does not work for some reason):
Code: [Select]
&02a4 = ff1d 010b 020c 030d 0502 060d 070e 0802 141a 280e 290d 2a1a 0902 0402 623a 633b 6917 fe56 0d46 2616 0e02 0f02 1002 1102 1202 3a02 3b0d 3c0e 1a18 7214 7312 7412 8950 ba13 bb10 0000 0000 0000

&02a4 =  FF1D 020C 030D 0502 060D 070E 0802 141A 280E 290D 2A1A 0902 0402 623A 633B 6917 FE56 0D46 2616 0E02 0F02 1002 1102 1202 3A02 3B0D 3C0E 1A18 7214 7312 7412 8950 BA13 BB10 0000 0000 0000

PS-Tool warns that the data length is unusual. But compare the last three entries 0000 that match "no sound" in config tool. So:

Code: [Select]
&02a4 = ff1d 0000 020c 030d 0502 060d 070e 0802 141a 280e 290d 2a1a 0902 0402 623a 633b 6917 fe56 0d46 2616 0e02 0f02 1002 1102 1202 3a02 3b0d 3c0e 1a18 7214 7312 7412 8950 ba13 bb10 0000 0000 0000
Finally something that works (besides changing friendly name)!
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1610
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #43 on: October 02, 2016, 09:58:59 am »
As I mentioned in a previous post, modifying things like default volume, name, feature list etc.. is ridiculously difficult to do just from the datasheet and manually editing hex dumps.  But using the nice 'headset configuration utility' which has a GUI results in a bricked module, because it only writes to certain addresses, and fills the rest with 0xFF (important things like boot config).  So the only way I have found is to Use PStools to read a working device config, save it, open config in headset configuration utility, change some settings and save as a *different* file, then compare the two... any values that have been changed in the later file, must be moved to the stored config whilst leaving the rest as is.  Only then can the config be written back, with all the same values except the few that were changed.

It's time consuming but only needs to be done once.  I haven't managed to get the I2S port working - I dont' think its enabled in the ROM anyway - but the on-board DAC is more than good enough
 

Offline none

  • Contributor
  • Posts: 32
  • Country: 00
Re: Programming off the shelf CSR8635 module
« Reply #44 on: October 02, 2016, 12:03:24 pm »
I followed that initially, but comparing the keys showed that the exported PSR file does not differ in data except for the changed values. It does have a header, different comments and some additional whitespace. However, merging the changes manuall into the PSTool's Dump file and then writing this to the device did not work either. Manually writing a single modified key with PSTool didn't work either. I suspect that some of the user code might rely on these values.
 

Offline Buriedcode

  • Super Contributor
  • ***
  • Posts: 1610
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #45 on: October 07, 2016, 04:06:38 pm »
It is most likely a ROM - there is no 'user code', only the firmware which is permanently burned in. And yes, the firmware is dependant on many of the values in the EEPROM, which is why its so easy to brick them.

When I compared the dump file from PStools, and the one created by the headset utility (you must 'open from device' first, then make changes, then save to file) I only noticed a few lines that were different, and as you rightly pointed out, it adds white-spaces, which don't make a difference.  But it also misses out key entries which is the problem.  That is why you make the changes to the dump from a working chip, rather than copy over the dump to the headset config output.
 

Offline kile

  • Contributor
  • Posts: 18
  • Country: hu
Re: Programming off the shelf CSR8635 module
« Reply #46 on: October 20, 2016, 01:37:55 pm »
Maybe I missed a pull-up or pull-down somewhere, or something like that.
Do you have debug SPI interface enabled by pulling CS (SPI) high?

The FTDI chip is supposed to the pull the CS pin high, right? I don't think I need to pull it up with a resistor. Is that correct?

In any case, it looks like the problem I had is with genuine FTDI chips. http://blog.bitheap.net/2012/03/ft232r-bitbang-mode-is-broken.html
If you have an FTDI knock off - everything works fine, if you have a genuine FTDI chip - bit-banging will not work. Nice, huh? :D

Then I learned you can also make an LPT programmer, and since I have an LPT port on my PC, I did just that. Then I learned LPT programmers are not supported on 64bit windows which I have. :( Not even through virtualization. :( Another bummer.

So I gave up and ordered a dedicated CSR programmer from ebay. I am waiting for it to arrive. I really hope this works, because I am running out of options.

Sorry for the very late reply but I haven't checked this thread in a while.
 

Offline ratep2001

  • Newbie
  • Posts: 1
  • Country: dk
Re: Programming off the shelf CSR8635 module
« Reply #47 on: November 18, 2016, 11:42:01 am »
I've also had success changing the name of the Sanwu amplifier (CSR6835 + TDA7492) with the procedure and hardware from TinyOS. 3 out of 3 boards were renamed although the one was more sensitive to cable positioning and curvature than the others.

However, I have also two almost identical bluetooth amplifier boards named QS audio (seems to be the same raw PCB and same component values on bigger components, but some of them look different), which are less noisy than Sanwu and therefore I wanted to use and rename these too. Unfortunatelly, following exactly the same method and using the same hardware like I used on Sanwu, I could not connect to the CSR6835 module of both QS audio amplifiers.

What is going on? Is it possible that QS audio boards are locked for SPI programming, or some programming fuse is intentionally interrupted/burned before leaving the factory in order to avoid messing around with the settings?
 

Offline beercohol

  • Newbie
  • Posts: 1
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #48 on: December 18, 2016, 11:33:16 am »
Hi Everyone, I'm adding myself to the list of headscratchers trying to program the CSR8635 when attached to the TDA7492P board (here: http://www.ebay.co.uk/itm/Wireless-Digital-Bluetooth-4-0-Audio-Receiver-Amplifier-Board-TDA7492P-50W-50W-/141738932730).

I'm using the CSR low-cost programming board (DK-USB-SPI-10225-1A) I purchased (here: http://bcdmicro.co.uk/shop.php#!/CSR-Low-Cost-Babel-USB-SPI-Debug-Programmer/p/50636001). You can see from the nice photo of the board, the SPI pins.

Now onto my programming attempt. I installed Bluesuite on my Windows 10 machine (including the USB>SPI driver) and loaded up PSTOOL. It can see the driver fine, the Programmer board power LED lights up when connected. So far so good.

Looking at the CSR8635 soldered to the amp board, I noticed the 7 square soldered tabs just south of the bluetooth module (pointing towards the push button controls). I noticed they were all connected to the relevant SPI pins, so using a very small pitch IC Socket (I don't know what the pitch is, but 4 pins seems to span 5mm to my dodgy eyesight). The pins conveniently touch those soldered tabs dead centre - so I used this as a convenient tool to touch the 7 tabs. I connected back from those tabs back to the CSR Programmer board (see attachment).

At this point I consistently get read failure. I suspect there may be some protection in place to stop me getting the CSR8635 into SPI programming mode. The SPI_EN connector on the CSR programmer board reads 3v when checked across the GND pin, so I am sure the CSI Programmer board is trying to put the CSR8635 into SPI mode.

I have ordered a separate CSR8635 module from china and will have to wait a month or so before it arrived before I can test a CSR8635 that is not installed onto the board. Other than that, I'm stumped.

It looks like I'm not the only one who wants to change the BT name in situ (on the AMP board), and those 7 tabs tell me the manufacturer must at some stage intended their use for SPI programming the board - probably once on the production line. But if they did anything else to the board to lock/disable SPI programming after that, it would be great to understand and defeat it.

Let's nail this one!

b.
« Last Edit: December 18, 2016, 11:43:49 am by beercohol »
 

Offline fixedcoil

  • Newbie
  • Posts: 1
  • Country: gb
Re: Programming off the shelf CSR8635 module
« Reply #49 on: January 02, 2017, 01:09:48 am »
I wrote this for another forum but thought it might be helpful to someone here, hence the redundant details about CSR.

DISCLAIMER: Everything written below is information I have gleaned from reading CSR documentation, blog posts and related comments. It is offered in good faith with no promises. What I relate worked for me, your mileage may vary but BEFORE changing any PSKey parameters you should DEFINATELY BACKUP your modules by dumping/writing their initial settings to file using both PSTool and the ROM Configuration Tool.

I recently bought a Sanwu Audio Bluetooth Audio Amp module on Ebay and was disappointed to find that it played loud discordant event tones when powering up, pairing, connecting and when the volume was changed. I just wanted to put it in to the ceiling void of my bathroom to be able to play music from my phone with better sound quality than that provided by the phones speaker.

The Bluetooth chip is by Cambridge Scientific Research (since bought by Qualcomm) CSR8635, designed to be used in a hands free a car phone, or similar, application. Searching online I not come across anyone also finding these features unwanted and solving the problem of removing them. I did find CSR information and programming software not easy to obtain but it is available if you look.

This document is written for a different device but the parameters seems identical:
http://read.pudn.com/downloads166/sourcecode/compiler/758171/BlueLab-3.6.2-release/3.6%20support%20documentation/docs/CS-110372-UGP2_BlueVOX_Configurator_User_Guide.pdf

This is the PSTool Users Guide:
http://www.52bluetooth.com/csr/adk3.0/adkdocs/CS-101505-UGP7PSToolUserGuide.pdf

To communicate with the module you need a USB/spi module. It is possible to DIY one but a CSR module can be found here:
http://www.broadband.se/shop/bluetooth/classic-bluetooth/programmer/csr-%C2%B5energy-low-cost-usb-spi-programmer/

There are spi lands on the Sanwu module to which fly leads can be soldered.

The 8635 configures itself when it boots by reading default parameters, called Keys from ROM. It can be customised by writing modified parameters into EEPROM which then mask and overide the corresponding default parameter. These modified parameters are called persistant store keys (PSKey). PSKeys are split into three groups. The first are fully locked down from manufacture, they configure the bluetooth radio and other regulated features. The second group contain the user configurable PSKeys; those from 0 to 24 are secure keys and need the CSR86xx Series ROM Configuration Tool to write to them. The keys from 25 to 49 can be written to using the PSTool.

The event tone parameters are stored in PSKey USR26. The format is four hex digits:
xxyy xxyy, where xx is the event and yy the tone to play. Setting all the yy digits to 00 removes the tones.

The Hands Free Profile is stored in USR3 and can be removed by simply deleting all between USR3 up to USR4. Alternatively the ROM Config Tool can be used to unselect the HSP and HFP profiles under the HFP tab.

Finally to change the module name from SanwuAudio use the PSTool, search for name, type in the new name and press Set.

 
 
The following users thanked this post: l0rd_hex


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf