Upload program to Mega via BT using HC-05

I'm trying to upload a program to a Mega 2560 using a Bluetooth link to a HC-05 BT module. I have configured the module to output a LOW on it's STATE pin when a connection is made, and confirmed that this is working properly. I also configured it to use 115200 baud in 'data' mode vs the default 9600.

Based on a number of posters who claim to have made this work, I connected the STATE pin output to the Mega reset pin via a 0.2uF cap (I didn't have any 0.1uF's available) and verified that a negative pulse appears on the reset pin when the HC-05 opens a connection.

I verified that I can pass data both ways through the HC-05 using RealTerm on my PC to connect to the HC-05 COM port, with my VS2017/VM setup connected to the Mega with a USB cable

However, when I try to upload a program, the loader times out (verbose output below). I can see the loader establish a connection to the HC-05 module, but nothing happens. I tried manually resetting the Mega with the reset button but that doesn't seem to affect anything either. I'm starting to suspect that there is some other unknown problem with the loader configuration.

Any ideas what I'm doing wrong here?

TIA,

Frank

Compiling debug version of 'BlinkTest' for 'Arduino/Genuino Mega w/ ATmega2560 (Mega 2560)'
Program size: 3,048 bytes (used 1% of a 253,952 byte maximum) (1.20 secs)
Minimum Memory Usage: 288 bytes (4% of a 8192 byte maximum)
 
Uploading 'BlinkTest' to 'Arduino/Genuino Mega w/ ATmega2560 (Mega 2560)' using 'COM27'
Uploader started for board Arduino/Genuino Mega w/ ATmega2560 (Mega 2560)
Upload method will be: bootloader
Uploading via Bootloader 
C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude "-CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf" -v -V -patmega2560 -cwiring "-PCOM27" -b115200 -D "-Uflash:w:C:\Users\Frank\AppData\Local\Temp\VMBuilds\BlinkTest\mega_atmega2560\Debug/BlinkTest.ino.hex:i"
avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch
         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"
         Using Port                    : COM27
         Using Programmer              : wiring
         Overriding Baud Rate          : 115200
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
The uploader process failed
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude done.  Thank you.

Does your Mega work fine with the USB port and you can load a sketch on it and communicate back and forth with the sketch in the serial monitor, and then switch to communicating back and forth with the sketch using bluetooth?

Yes, it works completely normally. I ran some tests where I sent ASCII characters back and forth between RealTerm connected to the HC-05 via BT and another serial monitor connected to the Arduino via USB, and this was completely successful. Everything works fine until I try to upload a program via BT.

You have not tried communicating between a sketch that is actually running on the Arduino, and the serial monitor on the PC. Do that first with the Arudino's built in USB communication. Then graduate to using BT to communicate between the sketch running on the Arduino, and the serial monitor on the PC. Do those things so you can know the BT module will work with the Arduino's main ATmega2560 processor on a basic level. THEN you can worry about whether or not it will work for uploading sketches. This is taking basic steps of progression. To do this you will need to write a sketch that can do something like take characters you type and do something with them, and send you back some text. Perhaps you can write an adding machine that works through the serial monitor. Something like that.

Also, tell us what AT commands you put into the HC-05 to program it for 115200 baud operation. You need to use the correct number of stop bits, parity, flow control, number of data bits, and things like that to make it compatible with what the ATmega2560 expects. And did the HC-05 write OK back to you for each of the commands you typed while programming it. Did the conversation while programming go something like this?

at
OK
at+orgl
OK
at+role=0
OK
at+polar=1,0
OK
at+uart=115200,0,0
OK
at+name=Arduino
OK
at+pswd=1234
OK

Depending on what terminal and settings you were using on the PC, you may or may not see the AT command text repeated back to you. And of course, you could have used other values for the name and password.

I just thought of a big hint that (I hope) will help you communicate via BT with a sketch on the ATmega2560. If you did your test through the Mega's onboard USB-to-serial adapter back to the computer, that means you must have had the TX and RX pins swapped so it would do that, instead of in the correct order to communicate to the ATmega2560. Remember, you had it hooked up backwards to make it talk back towards the computer along the USB wire, instead of talking forward to the ATmega2560.

Once you get it uploading using BT while timing the tap of the reset button with your finger, and have that going well, you can then fix the last piece, getting the auto reset to work. To do that, you will need to cut the Reset-EN jumper pad trace, to disconnect the onboard usb-to-serial adapter's DTR-to-capacitor-to-reset function. That onboard capacitor will interfere with your BT-state-pin-to-capacitor-to-reset functionality. Although in your case the 0.2 uF cap may be able to successfully overpower the onboard 0.1 uF cap, you may have trouble with the pulse shape and getting it working reliably every time. Your state pin is going to only be sending 3.3V, so the signal will not be as powerful as the onboard DTR signal from the USB chip (probably 5V).

Wow! Thanks for the detailed and informative reply! Sounds like you have travelled this road once or twice before yourself!

OK, so I'm not quite sure what you mean by

dmjlambert:
You have not tried communicating between a sketch that is actually running on the Arduino, and the serial monitor on the PC.

As I have done this many times on other projects (and on this one) with this same Mega. I have no trouble programming the Mega and conversing with it over the wired USB connection. Am I missing something?

I recorded all my work on my 'Paynters Palace' blog site. You can see everything at this link. Sorry to make you wade through the stuff you already know, but I thought this was the best way to show you the steps I have taken so far.

dmjlambert:
I just thought of a big hint that (I hope) will help you communicate via BT with a sketch on the ATmega2560. If you did your test through the Mega's onboard USB-to-serial adapter back to the computer, that means you must have had the TX and RX pins swapped so it would do that, instead of in the correct order to communicate to the ATmega2560. Remember, you had it hooked up backwards to make it talk back towards the computer along the USB wire, instead of talking forward to the ATmega2560.

Hmm, now I'm really confused; As I'm sure you know, I have no control over the Rx/Tx wiring between my PC and the USB connector. Between the Arduino and the HC-05, I have Tx1 on the Arduino connected to Rx on the HC-05 and vice versa. Are you saying that the HC-05 to Arduino connection should be Rx - Rx, Tx-Tx? If so, that's a new one on me.

Thanks again for taking the time to help me on this issue

Frank

paynterf:
Hmm, now I'm really confused; As I'm sure you know, I have no control over the Rx/Tx wiring between my PC and the USB connector. Between the Arduino and the HC-05, I have Tx1 on the Arduino connected to Rx on the HC-05 and vice versa. Are you saying that the HC-05 to Arduino connection should be Rx - Rx, Tx-Tx? If so, that's a new one on me.

Here is what I suggest. It is confusing to think about connecting a BT module to an Arduino. In fact, I would just say "you can't connect a BT module to an Arduino at all." Let's stop thinking about connecting BT to Arduino.

What you can do is connect a BT module to a specific chip on an Arduino. According to the text of this thread so far, I think you may be running 2 terminals on your PC, one connected to the USB port and one connected to the BT port. And you connect your wiring like this (scenario 1) to talk to the ATmega16u2 (or CH340G chip depending on brand) on the Arduino, which has the function of converting USB to serial and it does not really do any sketch running or accepting of sketch uploads.

scn1.jpg1239×992 152 KB

That will not communicate with the chip you really care about, the ATmega2560. So in wiring like this (scenario 2), you don't use the USB at all, and in fact it is best just disconnected. Use BT to talk to the ATmega2560. Then you can upload sketches to it, and communicate with any sketches that you have running on it.

scn2.jpg1257×1026 196 KB

scn1.jpg1239×992 152 KB

scn2.jpg1257×1026 196 KB

Scenario 2 as you described is exactly what I set up when attempting to program the Arduino using the BT module. I physically disconnected the USB cable, and used an external lab power supply to supply +8V to the Arduino's PWR jack.

From my blog post:

"For the next step in the testing, I need to remove the hard-wired USB connection and power the Arduino from an external power source. When I did this by first removing the USB connector (thereby removing power from the HC-05) and then plugged in external power, I noticed that the HC-05 was no longer connected to my laptop (the HC-05 status LED was showing the ‘fast blink’ status, and my connection indicator LED was OFF). I checked in my BT settings panel, and the HC-05 (now announcing itself as ‘H-C-2010-06-01’) was still paired with my laptop, but just transmitting some characters from my BT serial monitor did not re-establish the connection. However, when I changed the port number away from and then back to the BT COM port, this did re-establish the connection; the HC-05 status LED changed to the 2-blinks-pause-2-blinks cycle, and my connection LED illuminated."

However, although uploading a program did create a new connection to the BT module and did cause the STATE line to go LOW, no programming data was transferred. I'm not sure if this was due to some external cause (wrong baud rate, missing handshake of some sort, or other unknown cause), or because I can't get the Mega RESET timing right, or something else entirely. I'm now leaning toward one of those 'external' causes, because I can't get the programming to succeed even by manually resetting the Mega at the start of the upload process.

Still mystified, and still grateful for the help I'm getting here

Frank

OK for scenario 2 hookup, did you first upload and test a sketch on the Arduino using the USB cable, and communicate back and forth sending and receiving some text between the sketch and serial monitor? And that works? Only after that is known to work, then switch to using BT communication with that previously loaded sketch and using the serial monitor and verify it still works as expected? I suggest do that before trying to do something more complicated, such as sketch uploading.

dmjlambert:
OK for scenario 2 hookup, did you first upload and test a sketch on the Arduino using the USB cable, and communicate back and forth sending and receiving some text between the sketch and serial monitor? And that works? Only after that is known to work, then switch to using BT communication with that previously loaded sketch and using the serial monitor and verify it still works as expected? I suggest do that before trying to do something more complicated, such as sketch uploading.

I truly must be missing something here, as it seems to me that you are describing the normal way in which sketches are uploaded and tested. Upload a sketch with embedded 'Serial.print()' to the Mega and monitor output using the serial monitor. I did this several times just in this one project. This particular Mega board is my 'go to' test board and I've probably uploaded sketches to it 50 or more times since I received it.

So, the bottom line is - yes, I have verified that I can upload an arbitrary sketch to the Mega using the wired USB connector, and I can and monitor serial output using that same connector & cable. I have also verified that I can communicate TO the Mega using that same USB cable & connector.

Does that help?

Frank

paynterf:
I truly must be missing something here, as it seems to me that you are describing the normal way in which sketches are uploaded and tested. Upload a sketch with embedded 'Serial.print()' to the Mega and monitor output using the serial monitor. I did this several times just in this one project. This particular Mega board is my 'go to' test board and I've probably uploaded sketches to it 50 or more times since I received it.

I don't think you are missing anything. I am the one am missing some info. So, can't figure out what all has been accomplished so far, don't know the whole story to see where the gaps are in the process.

paynterf:
So, the bottom line is - yes, I have verified that I can upload an arbitrary sketch to the Mega using the wired USB connector, and I can and monitor serial output using that same connector & cable.

OK, good.

paynterf:
I have also verified that I can communicate TO the Mega using that same USB cable & connector.

How did you accomplish this?

My suggestion was to load a sketch on the Mega, make sure you can communicate with it thought the USB in both directions, that it would receive some text from your serial monitor, and receive some text back, perhaps different text such as would be produced if you made a calculator or something like that. That would ensure you are not just getting echoed characters back. Then without attempting to load another sketch, remove the USB cable, connect the BT module, and verify with the same serial monitor connected through BT. Check that the same behavior is observed when sending and receiving text to and from the Mega.

If you have done that and it is working fine, then the next step would be to verify several more things in preparation for upload via BT.

• Do you have your sketches that you would like to use operating at the same baud rate as the bootloader (115200), because the HC-05 can't arbitrarily change baud rates, it is programmed and then keeps that program for the desired baud rate.
• Upload with USB a sketch that gives some sort of indication that a reset has occurred. I usually use the blink sketch for that. When I go and try to do an upload using BT for the first time, I can notice a change in the blinking pattern, and that would be positive confirmation the processor is resetting. Another idea may be to use a sketch that blinks the pin 13 LED or some other LED that is attached externally a couple times during setup, and does nothing in the loop.
• I don't think you mentioned above whether or not you cut the Reset-EN jumper pad trace to disconnect the DTR signal that comes from the onboard usb-to-serial chip.
• I don't think you mentioned above what you did to program the HC-05 (what all commands you used and whether or not the OK message was received back from the HC-05 upon each command). Did you go through all of the commands I suggest in my earlier post?

If you are ready, go ahead and upload via BT and it should just work.

A note: I think with the default bootloader on the ATmega2560 doing a finger tap manual reset at the right time during upload is difficult, and the shape/duration of your reset pulse via that 0.2uF cap may be a problem. I'm not sure. There are other bootloaders for ATmega2560 such as Optiboot that may be friendlier, or you may find or can compile your own customized bootloader that stays waiting for beginning of upload longer, like 5 or 6 seconds.

When I have used BT to upload to my Mega, I have used a manual reset instead of using a DTR cap and a cut Reset-EN trace, and I will admit it is a pain getting the timing right. My experience with the auto reset using the state pin output going through a cap is with the Pro Mini and Pro Micro and UNO, and it works on those. I haven't done the BT upload with HC-05 and my Mega except for yesterday when your post made me curious, so I went and did it and it worked. You have to take my advice about the auto reset with a Mega part of the equation for what it's worth (not gold) because I have not actually done that one thing with my Mega.

Well, I took a few days off from the HC-05 upload project, to do some other things and to clear my head a bit.
Today I tackled the problem again and I'm happy to report success, although the solution had little to do with anything we've been discussing :-(.

To start with, I uploaded a modified version of the 'blink' program using the wired USB port on COM 8, where the onboard LED and a second LED are blinked rapidly 10 times, then just the onboard LED is blinked slowly forever. The idea here is that way I could easily tell when/if the Mega was reset. I also captured the verbose build output for this upload so I could compare it to the failed attempts via the HC-05 port.

After uploading this program, I verified that I can reset the Mega using the HC-05's STATE pin and the 0.22uF cap circuit. To do this, I created a connection to the HC-05 using RealTerm on my PC. All I had to do to reset the Mega was to change the port value from whatever it was to 27 (the HC-05 port) and click on 'Change'. After a few seconds the HC-05 LED changed from a fast-blink pattern to the 'connected' pattern (2 blinks, pause, 2 blinks), and the Mega reset successfully.

I also verified that the normal 'wired' reset pulse generated during a program upload was very similar to the pulse created by the HC-05 capacitor circuit - both are about 300 uSec long and show the classic capacitor charge/discharge shape when viewed on my Tektronix 2236 O'scope.

After this, I tried uploading the program via the HC-05 port, but it failed as expected. This time I captured the build/upload output and compared it to the earlier successful run. In particular I noted that the 'uploader' and 'bit rate' values are the same for the successful and unsuccessful runs, so I could eliminate bit rate issues as the cause of the problem. I also noted that even though the upload was unsuccessful, the Mega was indeed reset as soon as the upload attempt started.

After thinking about this for a while, I decided to try moving the HC-05 serial port connections from Tx/Rx1 (second hardware serial port on the Mega) to Tx/Rx0 (the port used by the now-disconnected USB cable). When I tried the upload again, it succeeded immediately!

So, the whole problem was that program upload is not supported on the Mega's Tx/Rx1 port. Apparently this problem does not occur with SoftwareSerial on arbitrary digital ports - who knew?

Frank

Good deal, problem solved. So you've been having avrdude bark up the wrong tree for a while. That's funny.

A bootloader is written to expect the upload on specific pins and using a specific protocol. You would be able to custom compile a bootloader to watch for an incoming program on UART1, or 2, or some other pins that use software serial, etc. The bootloader that comes with a Mega board is expecting the upload to come through UART0.

The Adafruit Pro Trinket has an unusual bootloader in that it watches for upload by 2 different ways, one is the USBtinyISP protocol on pins 2 and 7, and the other way is UART0 serial upload via a small Optiboot section of the bootloader. But I think those guys are probably the only to do such a thing, support 2 protocols on different pins in the same bootloader.

Yes, funny in a sadistic or masochistic way (depending on whether you are the coder or the Mega)

But, why does it seem to work for SoftwareSerial on any arbitrary pair of digital I/O pins, or did I miss a(nother) crucial step in all those tutorials that show it working?

Frank

I don't know about any tutorials. Whatever pins you connect a device to in order to upload, such as connecting a BT module or an FTDI adapter, you do need to make sure you have a bootloader installed on the ATmega2560 to match. So if you connect a BT module to pins 18 and 19 (for example), and you want to upload programs with it, then you need to compile a bootloader that will listen/talk on those pins and re-bootload the chip to have that particular bootloader.

Hmm,

Just ran a couple of tests using SoftwareSerial on pins 10/11 on the Mega, and couldn't get remote upload to work at all. So now I'm wondering about the tutorials where 'it just happens' using SoftwareSerial. Maybe they missed the step where they moved the HC-05 connection from the SoftwareSerial pins to the Tx/Rx0 pins? There wasn't any mention of a custom bootloader either.

Just sayin ;=)

Frank

All,

In an effort to help others who are interested in using the HC-05 for remote program upload to an Arduino-compatible microcontroller, and maybe save them from some of the frustration I experienced, I created what I hope is a comprehensive tutorial on my blog site (link). I would very much appreciate comments, especially if you see something that I got wrong or missed.

Special thanks to dmjlambert for all your help; you didn't provide the 'magic sauce', but you helped me eliminate everything else! ;-).

TIA,

Frank

Here is a fun fact you don't need. You can program the HC-05 using the UNO or Mega RX and TX pins with the blink sketch loaded on the Arduino. The MCU on the Arduino won't be doing anything with the RX and TX pins with the blink sketch running, so you can just hook up TX on Arduino to TX on HC-05, and RX on Arduino to RX on HC-05. And of course GND to GND and 5V to VCC. Scenario 1 diagram in post #6 earlier in the thread. Your HC-05 will be communicating with the USB-to-serial chip, and the computer. Program the HC-05 using the serial monitor set to 38400 baud. After the HC-05 is programmed and you are ready to use the HC-05 with Arduino sketches or for upload, swap the wiring to connect RX on Arduino to TX on HC-05, and TX on Arduino to RX on HC-05. Scenario 2 diagram in post #6 earlier in the thread.

The magic sauce was me trying to get to you to upload a program on the Arduino that communicates back and forth over the USB, then, without changing the sketch, go ahead and connect the HC-05 and communicate with the sketch. That would have required you to use RX0/TX0. You said you were using Scenario 2 hookup, but you were not, because you were not connected to the same RX/TX wires that go between the USB-to-serial chip and the ATmega2560. RX/TX on the ATmega16u2 or CH340G is connected to TX0/RX0 on the ATmega2560, the path that the bootloader uses. That's ok, we all learn this stuff in different ways, and you found the best way (your way).