Firmware dump

Firmware dump is done with the BlueFlash utility.

• Stop the processor: if the connection with the module is successful, information about the device will be displayed.
• Click Firmware ID to display the loader and stack version.

• Click Dump to dump the content of the firmware. Two files will be created: a XPV file and a XDV file.

The Bluecore chip family uses a XAP2 processor, a 16-bit RISC core designed for use in ASIC, with a Harvard architecture (separate data and instruction bus).

BlueFlash outputs one file for the data memory (XDV) and one file for the program memory (XPV).

Module settings dump

The settings of the module are stored in a persistent key-value store accessible with the PSTool software.

• Launch PSTool
• Select SPI BCCMD / LPT1 for transport protocol

Once connected you can browse all the module settings (radio calibration, protocol stack and application parameters).

• To dump the settings, click File/Dump and set a target PSR file.

The resulting file is a text file containing the value associated to each key in the persistent store. Here is for example the content of the application key USR1. This key contains my device current name “Shanghai” in ASCII.

Firmware update

The Bluetooth module firmware can be updated with the same tools: firmware download with BlueFlash and parameters update/merge with PSTool. The original XDV, XPV and PSR files of your module should be kept aside in case of a bad update. You should be able to restore your original firmware with those 3 files.

Also one must be careful with the radio calibration settings when updating a Bluetooth module. Radio settings are factory-calibrated to account for variability in the manufacturing process and thus are unique for each module. Overwriting those settings could really degrade the radio quality.

I am using the circuit published on Byron’s blog.

The SPI protocol is bit-banged on the parallel port of the PC. The 5V to 3.3V level adaptation is done using resistor dividers.

The SPI pins are accessed through a right-angle header on the bottom of the breakout board I designed.

The 3.3V power supply is supplied by a 3.3V Teensy2 that is also used as a serial-to-USB interface.

The difficult part is to find a PC with a parallel port . CSR also distributes an USB-SPI interface that should be more convenient with a modern laptop but that is also a little more expensive than a DB25 connector and some wires.

The Bluetooth module can now be programmed/configured using the BlueSuite tools. BlueSuite can be downloaded from the CSR support website after registration (Click Browse category tree…/Bluetooth PC Software).

What is on the board:

• Altera Cyclone IV EP4CE22F17C6N
• 32 MB SDRAM
• EPCS16 configuration device
• Integrated USB Blaster (Programmer and JTAG interface)
• Some peripherals: digital accelerometer, A/D converter, EEPROM, some leds and switches

A simple board powerful enough to get started with soft-core processors. My plan is to test system design based on the LEON3 GPL core from Gaisler Research.

Case reuse

One of the project goal was to reuse as much of the original speakerphone case as possible, including the power switch, volume control potentiometer, front leds and keyboard. I though that as the box already contained amplifiers circuits for the speaker and the internal microphone, I could try to reuse those as well and design my project around them…

I first poked inside the existing circuit to find a way to simply insert my circuit in the amplifier paths. But I quickly realize I would use more time trying to reverse-engineering the design instead of building my own.

Then the only constraint was to keep the existing PCB footprint to ease the integration with the original switches.

Prototyping

Here is the breadboard prototype in its final stage:

The design is build around an ATMEGA328 connected to an SD card through the SPI interface. Like in my previous audio player circuit, audio samples are played on a PWM output. The signal is filtered with an RC circuit and amplified by a LM386 to drive a 0.3W speaker.

The sound from the electret microphone is amplified by a simple transistor circuit found on Sparkfun.com and then connected to an ADC input of the microcontroller to be sampled.

The circuit is powered by a single 9V battery that provides a “high” voltage for the LM386 amplifier. A 3.3V regulator provides the digital power supply to the microcontroller and to the SD card.

I am using a 16MHz crystal for the extra speed bump despite the 3.3V voltage that would qualify this as “overclocking”.

High current draw from the SD card

One difficulty I met was having spike noise in the audio recorded by the microphone on the SD card. It appears the SD card draws a high level of current during write operations and this was affecting the stability of the microphone amplifier power supply.

Here is a capture of the signals on an oscilloscope while writing sectors on the SD card. The blue signal is the output of the microphone and the yellow signal is the input of the ADC pin:

I tried to add decoupling capacitors around the SD card VCC and around the microphone amplifier to no avail. One solution I finally found in an application note from Actel: use separate regulators for the digital and analog domains.

So I added a second 3.3V regulator to provide an AVCC power supply to my microphone amplifier and an AREF reference voltage for the microcontroller.

No more noise, problem solved.

Connection of the matrix keyboard

The keyboard of the phone is on a separate PCB including two leds. This keyboard is using a matrix configuration with 19 keys arranged in 5 columns and 4 rows. The handsfree key is surprisingly wired separately. Four separate wires allow to control 2 front leds, a green one and a red one.

The keyboard PCB was connected to the main PCB through to a 17-wire ribbon cable. I reuse this cable by soldering a 0.1” header on it.

Fitting the circuit inside the phone

Considering the project is a one-shot, I choosed to use veroboards to solder my circuits.

The big one will be the main board supporting the microcontroller, the SD card slot and a female header for the keyboard connection.

The upper-right board will be a power board supporting the two voltage regulator and the main power switch.

The lower-right board will be the analog board containing both amplifiers circuits and a slide potentiometer to adjust the speaker level. It will be connected to the microphone already molded into the case and from whom you can see the black and red wires on the picture.

The 9V battery will fit at the bottom of the case.

To ease the maintenance of the circuit, the boards will be connected together by wires secured by screw terminals.

Building the boards

Here is the power supply board:

The amplifier board connected to the power supply board:

The amplifier in action playing a sinus signal coming from my laptop audio output:

And here is the main board. The SD card slot is a holder for a microSD. It is soldered on a right angle pin header.

The main board has been cut to fit the prominent speaker magnet.

At the end everything fit together inside the case:

Wires everywhere. In fact I am not really a fan of veroboards. It is a little tedious to assemble without proper planning…

Hardware schematic

You could find the EagleCAD schematic along the source code files on the project repository: http://github.com/elasticsheep/babyphone

Coming next

The next post will details the software design side of the project. Stay tuned…

The final circuit has been built inside the phone enclosure, including amplifiers for the speaker and the microphone.

Playback and record modules are developped an tested but the application code only supports playback for the moment.

Next I need to improve the matrix keyboard driver to allow multiple key detection to trigger the record of a new sound. The key combination should be hard enough to prevent the boy from erasing existing message.

The plan has been to reuse as much of the old phone as possible : speaker, microphone, keyboard.

The prototyping began on a Teensy2 board starting from my previous WAV player project. It has now moved on an ATmega328 because USB Mass Storage is not required and I want to keep my Teensy for other projects.

Hardware is done. Software is almost done. I am now soldering the design on a veroboard to fit it inside its final case.

More details and pictures to come…

Having sold out the stock and seeing the interest for the board, I have ordered a new batch that is now available for sale.

The price at Olimex was interesting for prototyping but not for producing greater quantity. This new batch has been produced by PCBCart instead with same specification.

Order your board in the shop page.

The test boards

The first test board is the one already used for my slave test with a Teensy 2 as USB to serial adapter and power supply. This board will be the master one.

The second test board is powered by a USB connector and a 3.3V regulator. A serial connection is establish with my laptop through a Prolific PL2303 adapter. This board will be the slave one.

Slave module configuration

The slave module is powered up in command mode. Cu does not seem to work correctly anymore with the PL2303 so I use screen instead:

$>screen /dev/cu.serial 38400
AT+ADDR?
+ADDR:11:3:252002
OK
AT+UART?
+UART:9600,0,0
OK
AT+ROLE?
+ROLE:0
OK

Role=0 is for the slave mode. I keep the default 9600 baud UART speed.

The module Bluetooth address will be useful to establish the connection from the master module.

Master module configuration

The master module is powered up in command mode. The role is changed to 1 for master. The UART baudrate is set to the same as the slave module.

$>sudo cu –s 38400 –l /dev/cu.usbmodemXXXX
AT+UART?
+UART:115200,0,0
OK
AT+UART=9600,0,0
OK
AT+UART?
+UART:9600,0,0
OK
AT+ROLE?
+ROLE:0
OK
AT+ROLE=1
+ROLE:1
OK
AT+ROLE?
+ROLE:1
OK

To establish an automatic connection to a slave module, the master module must know the slave address. This is configured with the AT+BIND command with CMODE=0 (Use a predefined address).

AT+CMODE?
+CMOD:0
OK
AT+BIND=11,3,252002
OK
AT+BIND?
+BIND:11:3:252002
OK

With CMODE=1, the master can connect to any device in its transmission range, so it is a much less secure configuration.

Master/Slave automatic connection

Now that the two modules are setup, I power up them in automatic mode (PIO11 = 0).

On each module, the red leds connected to PIO8 blinks quickly. After less than 2 seconds, the green led connected to PIO9 is shining on both modules indicating that they are now paired and connected, ready to transmit data.

I connect a terminal to the serial port of each module with their respective adapter to test the communication:

The first window displays the connection to the master BT module. The second window displays the connection to the slave BT module.

The connection is successful at 9600 bauds. I also successfully tested the communication at 115200 bauds.

Soldering the module on a breakout board

The difficulty is to correctly align all the module pins to the breakout pads. The module is so light that it can moves just because of the solder surface tension.

Two rows of header are added to fit in a prototyping breadboard.

Teensy 2 USB-to-Serial profile

I use the USBtoSerial project from LUFA 101122.

I already covered how to compile this project for the original Teensy in this previous post (Testing the LUFA USB Serial with GPS data). I apply the following modifications to the makefile:

MCU = atmega32u4
F_CPU = 16000000   

Here is the binary: Teensy2-USBtoSerial.hex

To connect to the virtual serial port on a Mac:

$> sudo cu –s 9600 –l /dev/cu.usbmodemXXXX

A quick loopback test (direct wire from TX to RX) confirms that the profile is correctly working.

Useful to exit cu: ~.

Connections between the Teensy 2 and the BT module

The TX pin of the BT module is connected to the RX pin of the Teensy 2, and the RX pin on the TX pin.

My Teensy 2 board has been patched with a 3.3V regulator (see Converting the Teensy2 to 3.3V). I will use it to power the BT module.

The TX pin of the BT module is connected to the RX pin of the Teensy, and the RX pin on the TX pin.

Two leds are connected on PIO8 and PIO9 to display the status of the BT link.

The PIO11 pin is used to select the boot mode:

• High => Command/Response mode where you can issue AT command to setup the module.
• Low => Slave or master automatic operation.

Module configuration

I connect the PIO11 pin to the 3.3V rail. In this mode, the baud rate is 38400.

I open a cu session in the terminal and communicate with the BT module over its serial interface:

$>sudo cu –s 38400 –l /dev/cu.usbmodemXXXX
Connected.
AT
OK
OK
OK
OK

The module sends the OK response repeatedly. Sending Ctrl-C can stop it. Then you can enter another commands.

AT+VERSION?
+VERSION:2.0-20100601
OK
AT+NAME?
+NAME:HC-05
OK
AT+ADDR?
+ADDR:11:3:252009
OK
AT+UART?
+UART:9600,0,0
OK

We can see that the module is currently configured for 9600 bauds operations with 1 stop bit, no parity.

I speedup the baudrate to 115200 bauds.

AT+UART=115200,0,0
OK
AT+UART?
+UART:115200,0,0
OK

I also change the role to slave-loop. In this mode, the module sends back all data it receives over the BT link. It is useful to check that the module can correctly receive and send data over the BT link before connecting it to your system.

AT+ROLE=2
OK
AT+ROLE?
+ROLE:2
OK

Now I power up the module with the PIO11 connected to GND to boot in autoconnect mode.

Pairing with a Mac

The connection of Bluetooth devices is handled by the System Preferences/Bluetooth panel.

The connection fails because the default passkey of the module is 1234. It can be changed with the AT+PSWD command.

The module is now successfully paired with the Mac but currently not connected.

It is recognized as a virtual serial port and corresponding devices are automatically created in the /dev directory:

$> ls /dev/*HC*
/dev/cu.HC-05-DevB	/dev/tty.HC-05-DevB

Slave-loop connection

I can now connect to the BT device and use it as a classic serial interface. In slave-loop mode, the characters are echoed back to the terminal.

$> sudo cu –s 115200 –l /dev/cu.HC-05-DevB
Connected.
ABCDEFGHIJKLM

The status of the bluetooth connection is reflected in the System Preferences panel.

Slave mode

I switch to the command/response mode and change back the role to slave:

AT+ROLE=0
OK
AT+ROLE?
+ROLE:0
OK

In this mode, the BT module acts as a full duplex serial interface. The data received over the BT link are forwarded to the its TX pin, while the RX pin incoming data are sent over the BT link.
So to test the connection I open two cu sessions. One is connected to the BT module, the other one to the Teensy 2 serial emulation. As the 2 devices serial pins are connected together, I am able to send characters on one session and receive them on the other sessions.

The first window displays the connection to the Teensy 2. The second window displays the connection to the BT module.

Go to the Shop page if you want to get one.