For my embedded course at the University of Lucerne of Applied Sciences and Arts I needed more Bluetooth modules for the Zumo/Sumo robots. I run out of stock as the modules are getting popular and are used in many student projects. So I ordered a handful more from DX/DealExtreme of the same HC-06 type/part number I already ordered a while back. I expected that they will work as the modules I had ordered from DX half a year ago. Was that naïve? Probably. Because they did *not* work, and caused me to reverse engineer the modules and to apply a hardware fix to get them working….
Failed to get Response from V1.06 Module
I wired up a V1.06 module with one of my FRDM-KL25Z boards, using 9600 baud (usually the default baud setting):
But wen I tried to communicate to the module, it failed: No response back from the module, or unknown response:
Checking with the signals with a logic analyzer shows that the microcontroller sends the ‘AT’ command, but no response back from the Bluetooth module:
I checked all the wires, and they were looking ok. Maybe a different baud by default on the module? I tried 2400, 4800, 14400, 38400, 57600, all did not work?
I tried the other modules: all failed, so it was not a single failure :-(.
Connecting to Host PC
Maybe it has a different firmware (see this post about different firmware)? If it responds as HC-06 to the host, I know it has the correct firmware on it.
And indeed, the board shows up with ‘HC-06’, as expected:
I can connect to it, and asks me for the Pairing Code, and it accepts the default pairing code 1234:
I was able to connect to the board from the host PC, and the red LED turned on permanently (good!). But whatever I send from the host to the Bluetooth module, does not arrive at the microcontroller :-(.
Communication from Microcontroller to Bluetooth Module works?
In desperation, I tried the AT+Name command with 9600 baud to assign the name ‘Hola’ to the module. The module did not report back to the microcontroller. But to my surprise, the module showed up with the ‘Hola’ name on the host!
So, that’s interesting! It tells me that:
- The module is able to connect with the host (ok!)
- The default baud is indeed 9600 (ok!)
- The microcontroller is able to communicate with the module (ok!)
- However, the microcontroller does not receive anything from the module (NOT ok!)
I verified this with the module connected: the AT commands from the microcontroller end up at on the host:
And all my existing modules work as expected, so it is definitely not a wiring or software issue. But then I realized: the new boards have a different version number on the board!
To inspect the differences, I removed the shrink tube around the board with a sharp knife cutting the tube on the side (be careful!):
💡 I carefully cut the tube on the side so I can fix it later (see below) with a scotch tape.
Board bottom side:
Board Top side, with the HC-05 pin functions as I know it (see this post):
Made direct connection to the Rx and Tx pins of the module:
With this I can see what is getting to the connector, and what ends up at the Bluetooth module itself. Sending an AT from the Microcontroller shows that the command arrives at the Bluetooth module too:
On the other end, if I send a ‘Hello!’ from the host, it arrives at the Bluetooth module Tx pin (which goes to the microcontroller Rx pin), but not at the connector to the microcontroller:
The string from the host arrives on the Tx pin with 9600 baud too: so definitely my baud settings are correct. So what is wrong that nothing arrives on the connector pin to the microcontroller?
No Schematics? Reverse Engineering of the JY-MCU BT_BOARD V1.06
I searched the internet, but there are no schematics available for the JY-MCU board. And if there are, then only for older boards like the V1.03. So I had no choice than to reverse engineer the connections of the SMD parts on the board :-(. With inspecting the traces on the board and probing the contacts, and this took me a while…
The back side does not give much details, but some vias are connected to the pins of the HC-06 module:
The front side with all the SMD parts is more complicated, but more interesting:
- 104: 100k Ohm Resistor
- 102: 1k Ohm Resistor
- 331: 330 Ohm Resistor
- B2: This seems to be a diode. Schottky Diode? Zener Diode?
- 662K: 3.3V, 0.5A fixed regulator
- 4 Capcitors of unknown capacity?
After some time, I came up with this wiring of the components:
- KEY has a 100k pull-down to ground and is connected with a 1k resistor to the key pin (26) of the Bluetooth module. I have not tried it yet, but with pulling that pin to 3.3V while powering the module, the module should enter AT mode.
- VCC is connected to the 3.3V fixed regulator, producing the 3.3V for the module. The Schottky diode is added as protection, and 4 C’s (unknown capacity) are used for voltage stabilization.
- GND is connected to the ground plane 🙂
- Rx: Pulled-up to 3.3V with a 100k resistor, with a 330 Ohm resistor to the Rx (2) pin. Looks like that resistor is used for 5V Rx signals from the microcontroller?
- State is directly connected to the State pin 25 of the module. I have not checked the function, but I believe it should show if the module is connected or not.
- Tx: there is a diode between the Tx connectors?
❓ It is not clear to me why there is this B2 diode on the Tx line? Line protection? But definitely it prevents my board to receive the incoming data from the Bluetooth module 😦
UPDATE: See comments section at the end of this post:
“I was also puzzled why they would add a diode on the TxD pin. It will not provide any protection to the module (unless your electronics were to apply a negative voltage to the Tx pin). However, it would have a use if your electronics were powered off and the Bluetooth module stayed powered on: without the diode then the Bluetooth module would attempt to power up your electronics through the Tx pin. It would fail, of course, but many milliamps would flow and battery life would be reduced. This is a reasonable use case I think: Bluetooth module stays awake while the main electronics is powered off.
My suggestion: turn on the pull-up resistor on the KL25Z RxD pin, that connects to the module Tx. Your scope traces show it is not present. Then the Bluetooth module will pull the signal to logic 0 through the diodes and the pull-up resistor will pull it to logic 1, and all should be well…”
💡 And indeed: adding a pull-up resistor to the Tx line (Tx from the module to the Rx of the microcontroller) solved the problem too 🙂 (like removing that diode on the Rx-to-Tx as described below.
So I tried with bypassing the diode with a wire:
And indeed: now the communication works both ways like a charm!
Removing Tx Diode
So the logical step was to remove that Diode in the Tx line:
Then to solder a wire bridge instead:
And finally taped the shrink tube around the module to restore the original state:
Violà: now communication is working both ways:
Cheap parts from China might mean that I need to be prepared for surprises: things before working might change without notice. And because it is hard to get schematics, things will be hard to find a problem. That diode does not make much sense to me, but definitely prevents to get the module working with my FRDM-KL25Z board (at least with 3.3V logic levels).
I hope that this post is useful for anyone else who might receive the V1.06 modules and has problems to get it working with a 3.3V microcontroller :-).
With all the comments (thanks!), I was able to solve the problem without hardware modification :-). The solution is to pull-up the Tx signal to the microcontroller (Rx for the microcontroller) either with a hardware pull-up or with a software pullup. In my example, Rx is on PTC3:
#include "PORT_PDD.h" PORT_PDD_SetPinPullSelect(PORTC_BASE_PTR, 3, PORT_PDD_PULL_UP); PORT_PDD_SetPinPullEnable(PORTC_BASE_PTR, 3, PORT_PDD_PULL_ENABLE);
Happy Bluetoothing 🙂