# Bluetooth RN42 module enters Command mode - deaf afterwards

#### atferrari

Joined Jan 6, 2004
4,632
PIC micro 18F452 to control an RN42 module. PSU for the module, level converter (5 <>3V3) and USART, all previously tested, working OK. Module's CTS kept low since the start.

Within the first 60 seconds after power up, the RN42 recognizes the $$command, returning CMD with GPIO5 starting to blink a LED at 10 HZ, all as expected. Whatever I send after, whether a correct command of any type, garbage or just --- to exit, the RN42 does not react. The module's TX pin shows no activity at all. There is hope because the 1st command being recognized, but then...what am I doing wrong? #### sailorjoe Joined Jun 4, 2013 364 Couple of questions. How are you connected up and generating the commands to the RN42? You said there's no activity on the Tx pin from the RN42. Is there activity on the Rx pin? Just checking to make sure the RN42 is getting sent something. Is GPIO7 on the RN42 pulled high or low? More importantly, does it change somehow between when things work and when they stop? GPIO2 and GPIO5 are status outputs. What do they read before and after things stop working? Thread Starter #### atferrari Joined Jan 6, 2004 4,632 How are you connected up and generating the commands to the RN42? Level converters between micro and module. At the press of a button the command is sent. No extra delays other the intrinsic ones testing TXIF and RCIF flags. You said there's no activity on the Tx pin from the RN42. Is there activity on the Rx pin? Just checking to make sure the RN42 is getting sent something. Sure, commands reach that pin. Is GPIO7 on the RN42 pulled high or low? More importantly, does it change somehow between when things work and when they stop? Kept firmly high by a pin from the 18F452, setup in software prior starting. GPIO2 and GPIO5 are status outputs. What do they read before and after things stop working? GPIO2 steadily low. GPIO5, initially blinks slowly. As I posted, after acknowledging with "CMD" it starts to blink faster - and stays like that forever. BTW GPIO8 seems steady high since the start. Have to check it with my scope now that I think of it. Thread Starter #### atferrari Joined Jan 6, 2004 4,632 http://ww1.microchip.com/downloads/en/DeviceDoc/rn-42-ds-v2.32r.pdf This link, on page 7, shows the meaning of the status pins. Looks like the RN42 is waiting to connect to another Bluetooth device. Blinking faster than 1 HZ (change to 10 Hz is easily perceived), it is saying "the module is in command mode". The sole thing I am sure about is that it has issued a "CMD" in response to my "$$$" thus I find illogical the module being ready to connect. Let us call my tablet to help and see what I find. Rechecked everything and my micro does all what is expected. The module does not go further past entering command mode. #### sailorjoe Joined Jun 4, 2013 364 Let me make sure I understand, please. GPIO5 blinks more than 1 Hz but less than 10 Hz. GPIO2 starts and stays Low. And GPIO8 starts and stays High. Please correct me if that's not correct. I'll come back after more research. Are you using RTS/CTS control signals from the micro to the RN42? Do you have this document? http://ww1.microchip.com/downloads/en/DeviceDoc/bluetooth_cr_UG-v1.0r.pdf After receiving "CMD", what does the micro send to the RN42? Last edited: Thread Starter #### atferrari Joined Jan 6, 2004 4,632 Hola SJ, I moved one step forward. I am getting a reply to any command I send albeit at the display is still garbage. (My code sure is the culprit). The change is simply this: following all commands (except$) with a CR (H'0D').

Tomorrow I am going to check your post again and see where I am.

Thanks.

#### atferrari

Joined Jan 6, 2004
4,632
Hola again SJ,

From the current documentation provided by Microchip. Looks reassuring, isn't it?

#### sailorjoe

Joined Jun 4, 2013
364
Good, making progress.
Garbage sounds like either a baud rate or a a buffer overflow problem.

#### atferrari

Joined Jan 6, 2004
4,632
Good, making progress.
Garbage sounds like either a baud rate or a a buffer overflow problem.
With a 4 MHz xtal I use 9600 bauds. It works fine.

Now I know what the garbage was: my code was displaying the trailing <CR> and <LF> sent by the module. Corrected.

Managed to finally get an idea of what should I do next. Going to the tablet side to see how I will read what the micro sends. I supose is going to take some time to have positive news.

Thanks for you interest.