Created by Scott Schmit, last modified by BenH on Sep 01, 2016
The RN42 is a Class 2 certified Bluetooth module from Microchip. It includes an embedded Bluetooth stack that supports SPP and DUN Bluetooth profiles. A special version of firmware also supports HID Bluetooth profile. A PCB trace antenna was included on the module to eliminate the need for antenna design and castellated edges make the module simple to solder onto any baseboard. Any host device can interface with the module through a simple UART interface. The RN42 supports baud rates up to 3Mbps and SPP data rates up to 300kbps (master). This page is meant to help familiarize you with these modules. You will find some useful links and downloads below, as well as some tutorials and design considerations on various features of the module. The RN-42-EK board was used as a simple evaluation board for the module.
- RN42-I/RM - Class 2 certified Bluetooth module with PCB trace antenna
- RN-42-EK - Eval board for RN42 module
- RN42 Landing Page - Microchip online product page
- Tera Term - Free terminal emulator software for serial communication with PC
The RN-42-EK board was used to evaluate the RN42 module.
If your computer has a built-in Bluetooth adapter, you can use that to communicate with a single RN42 module. If you don’t have a built-in Bluetooth adapter in your computer, you can still experiment with the RN42…you’ll just need two modules. You can connect the module(s) to your computer using a hard-wired connection. I would recommend using the RN-42-EK board to evaluate the module since it comes with an on-board USB interface. You don’t need to worry about interfacing with any USB/UART bridge cable. The RN-42-EK comes with everything you need to start prototyping with the RN42.
Here are some additional items you might find useful:
- 2mm, 1x12 male header: 951112-8622-AR
- 2mm, 1x12 female R/A header: 950512-5002-AR
- 0.1", 1x6 male header: S1011EC-06-ND
Setting Up Your Terminal
Once you have your module hard-wired to your computer, you need to setup your terminal software with the proper settings to properly communicate over UART. There are many free terminal programs available like Tera Term or RealTerm. If you are running Windows XP, you will have HyperAccess installed by default. Tera Term is my terminal emulator of choice. It supports multiple serial communication protocols, file transfer protocols, and also has a built in scripting language. For the purposes of this page, we are just interested in simple UART communication, so I will show you how to configure Tera Term to communicate with these modules.
- Download Tera Term (link)
- Open a Tera Term window
- Make sure the RN42 is properly connected to your computer and that it is powered on
- Select the “Setup” dropdown from the Tera Term menu bar
- Click on “Serial Port”
- Select the port corresponding to whatever bridge device you are using. You may need to wait for the USB driver to finish installing.
- Use the following serial settings:
- Baud: 115,200 (use 9600 if jumper 4 is set)
- Data Bits: 8
- Parity: None
- Stop Bits: 1
- Flow Control: None
- You can leave transmit delay set to zero.
- Press OK to apply your changes.
You should be ready to communicate with your module over UART. To test it out, type the characters ‘$$$’ and you should get ‘CMD’ as a response. If not, double check your connections and serial settings. Make sure all the Ground pins are connected! If you want to see every character that you type, you can turn on local echo by selecting “Setup” from the menu bar and clicking on “Terminal”. The “Terminal Setup” dialog box has a check box for enabling/disabling local echo. Also, within the “Terminal Setup” dialog box, I like to set the New-line Receive setting to CR+LF. That way when you send a command to the RN42, it will send a newline before displaying a response.
RN42 UART Commands
I know you want to start wireless transmission right away without even having to think, but just tap the brakes for a minute. Let’s take a quick look at some of the UART commands as they will be involved in later sections.
There are four types of UART commands for the RN42:
- Get Commands: Used for reading configuration
- Set Commands: Used for setting configuration. Need to reboot or power-cycle the device for “Set” commands to take effect.
- Change/Action Commands: Used for temporarily changing settings or causing immediate actions
- GPIO Commands: Used for manipulating I/O pins
The module must be put in Command Mode in order to properly receive commands. This is accomplished by sending ‘$$$’ over UART. You should get ‘CMD’ as a response indicating the module is in Command Mode. Type ‘X’ and press to view all of the current settings for the module. To exit Command Mode, send three minus signs and press enter (- - -).
The image shown to the right displays the serial readout after sending the ‘X’ command. We can see the firmware revision and date loaded at the top. Then we see the General Settings section which includes the module’s Bluetooth address, name, UART baudrate, mode of operation, authentication setting, 4-digit pin code, whether or not bonding is enabled, and the remote address stored in memory. Next, we see the Advanced Settings which are specific to the Bluetooth standard and how you want your link setup. We won’t mess with any Advanced settings on this page. At the bottom of the readout, we see the Other Settings section. This is where you can set the Bluetooth profile, CMD character, enable sniff mode, enable low power mode, change the TX power, set/read I/O pins, set/read the sleep timer, enable Debug mode, and switch roles.
I recommend reading through all of the available commands in the Command Reference Guide. For now, let’s just touch on a few important ones.
Connecting to Remote Devices
Alright, it’s time to get our hands dirty.
By default, SSP authentication is enabled on the RN42 module. That means that the host will receive a prompt and you will need to confirm that you want to pair with the device. This allows you to easily connect a single RN42 with a PC or Android device. You simply confirm you want to pair with the slave, and begin wirelessly transmitting data (you may need to enter the default pin 1234 to pair with the device)…but what if you’re not using your computer’s built-in Bluetooth adapter? If you have two RN42 modules that you want to automatically connect to each other, the default authentication setting will cause problems. By default, two RN42 modules won’t automatically connect without software configuration. You’ll need to change the authentication setting to a value of either 0 (for Open Mode) or 4 (for Pin Code mode). Open mode will disable authentication and allow connection without a passcode or verification of any kind. Pin Code mode will require a 4-digit code to complete the connection. The default pin code for the RN42 is ‘1234’ which is hard-coded into every module. Since the pin code matches in each device by default, Authentication setting 4 will allow automatic connection between two RN42 modules. Here’s a breakdown of how to change the Authentication setting (remember if you are connecting a single RN42 to your computer, you don’t need to worry about this):
- Connect your RN42 to your PC and make sure the module is powered up.
- Enter command mode by sending ‘$$$’ (should get ‘CMD’ response)
- Use the SA command to change Authentication setting (SA,0)
- Reboot the device to save and apply changes (R,1)
- Repeat steps 1-6 for the second RN42 module
Once authentication is disabled, the module can be bootstrapped to an automatic configuration using the appropriate I/O settings. To enable automatic communication with no host controller configuration, externally drive PIO3 and PIO6 high on one device and only PIO3 on the second device. This can be done using external jumpers, dip-switches, or pull-up resistors. For safety reasons, you should always use a pull-up resistor between the I/O pin and VDD, even if you are using jumpers or dip-switches (see Manipulating GPIO section below for details). On power up, as long as authentication is disabled, the devices will automatically connect and then any data received over UART will be immediately transmitted to the remote device. It’s a good idea to power the slave device first and wait a few seconds before powering up the master. The master will typically fail to pair with the slave if they are powered up simultaneously. When connected, the green LED on the RN-42-EK will turn solid green.
The connection process can be completely software controlled if desired. One of the devices will need to be configured as the master. You can externally drive PIO6 high (with pull-up) to enable auto-master mode, or you can manually configure the module as a master using the SM command. If you know the address of the remote device you want to connect to, you can hard code the address into the master using the SR command. If you don’t know the address ahead of time, you’ll probably want to scan for devices using the I or IN commands. The IN command is faster, but doesn’t return the Bluetooth name (see Command Reference Guide for more information). Here’s a breakdown of how you would use the SM, IN, SR, and C commands to connect to a remote device through software:
- Connect two RN42 modules to your PC and make sure each module is powered up.
- Setup separate serial ports for each device with the settings listed in the Setting Up Your Terminal section above.
- Put each module in command mode by sending ‘$$$’ (should get ‘CMD’ response)
- Configure the first device as a master using the ‘SM’ command (SM,1)
- For each module, make the Authentication setting ‘0’ or ‘4’ using the SA command (SA,0)
- Reboot the slave device to apply the new configuration using the ‘R’ command (R,1)
- Have the master perform a 10 second scan using the ‘IN’ command (IN10)
- If the slave is within range, the master should find it and spit out its address.
- Use the ‘SR’ command to store the address of the remote device (SR,)
- Reboot the master device to apply the new configuration using the ‘R’ command (R,1)
- Enter command mode again on the master by sending ‘$$$’ (should get ‘CMD’ response)
- Use the ‘C’ command to connect to the address stored in memory (C)
The screenshot below shows the terminal windows during the manual connection procedure for the master and slave devices on the left and right, respectively. You can see the slave device was the third device found in the Inquiry scan (Roving Networks devices use the 0x1F00 COD). There is no feedback in the terminal that you have successfully connected to the remote device except to try sending characters. After connecting, characters typed in one terminal appeared in the second terminal. You can physically see the LED turn solid green on each RN-42-EK board when they have successfully connected.
Master (left) and Slave (right) Terminal Output During Manual Connection
Sending Wireless Data
Once the master and slave are connected, the Bluetooth link is seen as a transparent serial (UART) connection between the two hosts. In the example above, two PC terminal programs were used as the hosts and ASCII characters were used as the data. However, a microcontroller could also be used as the host controller for the RN42. Anything transmitted over UART will be received wirelessly by the remote device. The exception to this is if one of the modules is placed in Command Mode. As long as a module is in Command Mode, nothing will get transmitted wirelessly. However, as long as you don’t mess with the link settings, the modules will remain connected and wireless transmission will resume once Command Mode is exited (- - -).
Note: The “T,1” command can be used to enable Bluetooth transmission while in Command mode.
The RN42 has a handful of GPIO pins that can be used for miscellaneous purposes. If you are using a microcontroller or FPGA to control the RN42, this gives you the opportunity to increase your I/O count. If you are using a terminal program as your host, it gives you some command based control over some digital I/O pins. Most GPIO pins are used by the firmware in some way. I would recommend not using the GPIO if you don’t need to. If you need to use the GPIO pins on the RN42, I would recommend using GPIO9~11. These pins can only be used as outputs, but they aren’t used by the firmware in any way. GPIO3 and GPIO6 can be used if auto-connect isn’t desired and could be used as digital inputs.
Here is a breakdown of the GPIO pins on the RN42 and how they are used by firmware.
|Available GPIO||Default Function||Applicable UART Commands|
|GPIO2||Output - Status Pin (1=connected, 0=disconnected)||Not recommended for miscellaneous use.|
|GPIO3||Input - Auto discovery (high to enable)||SQ,4 S@ S& S% S^|
|GPIO4||Input - Restore Factory Defaults||Not recommended for miscellaneous use.|
|GPIO5||Output - Status Pin, toggles based on state, low when BT connected||Not recommended for miscellaneous use.|
|GPIO6||Input - Set BT Master (1=auto master)||SQ,4 S@ S& S% S^|
|GPIO7||Input - Set UART Baud Rate (1=9600, 0=115200/firmware control)||Not recommended for miscellaneous use.|
|GPIO8||Output - RF data TX/RX||Not recommended for miscellaneous use.|
|GPIO9||Input - pull-down enabled||G* S*|
|GPIO10||Input - pull-down enabled||G* S*|
|GPIO11||Input - pull-down enabled||G* S*|
See the RN42 UART Commands section above for command-based usage of these pins.
Note: If you are designing a custom board and plan on utilizing GPIO3, 4, 6, or 7 and their hardware bootstrapping features, you need to use pull-up resistors between these pins and Vcc, even if you are using jumpers or dip-switches. If you don’t use pull-ups and connect Vcc directly to one of these pins, it will be fine as long as they are configured as inputs. But if you unintentionally configure one as an output, and Vcc is connected to one or more of these pins, you will have a dead short from VCC to GND which could wreck your module and/or power supply. There is no downside to adding pull-up resistors other than it takes a little bit more board space and adds pennies to your design cost. Both are negligible tradeoffs for most applications. You’ve been warned…do yourself a favor and USE PULL-UPS .
Restoring Factory Settings
There are a variety of reasons why you may want to restore factory settings. You could have misconfigured something and want to start from scratch. Maybe you are pulling a module from the field and want to restore factory settings while it sits on a shelf. It’s also possible that you are unable to communicate with the module locally due to UART baud rate or framing issues. Whatever the reason, rest assured there are a couple of ways to restore factory default values.
If you are unable to communicate with the module locally over UART, or if it’s simply more convenient to perform a hardware restore, GPIO4 can be used in a special sequence to restore factory settings to the RN42. It’s typically recommended to break out GPIO4 to a jumper or dip-switch with a pull-up to VDD to make it easy for the user to control GPIO4 externally. Here is the procedure for a hardware restore:
- GPIO4 must be pulled high on power up. The green LED on the eval kit will blink 2-3 times very quickly on power-up indicating that it’s watching for the rest of the sequence.
- Toggle GPIO4 low.
- Toggle GPIO4 high.
- Toggle GPIO4 low.
- Toggle GPIO4 high. The green LED on the eval kit will blink 2-3 times very quickly indicating that the module has been reset.
It’s recommended to wait approximately 1 second between toggling GPIO4.
If UART communication with the RN42 is readily available, it’s very easy to restore factory settings using the SF command. The SF command will reset all settings except the module’s Bluetooth Name. Here is the procedure for a software restore.
- Power the module up and setup the UART link.
- Put the module in command mode by sending ‘$$$’ (should get ‘CMD’ response)
- Use the SF command to restore factory default values (SF,1)
- Reboot the device to apply the settings using the ‘R’ command (R,1)
You can verify settings were restored by entering command mode and sending the ‘X’ command.
Comments from the author
The purpose of this page was to help you get started with RN42 modules and make it easier for you to implement them in your own design. They are very handy modules that make Bluetooth communication easy to achieve and take care of much of the required FCC testing for you. However, they do have a few quirks to them that can be frustrating at times and I hope this page eliminates some of that frustration. I hope you enjoy experimenting with the RN42 from Microchip!
- Scott S.