Upload to Mega via HC-12 problems

Connection Test Results Arduino 2560 Mega:

Comm Reset Upload
Full Duplex
Using a straight USB cable plugged into port on the Mega,
internal reset enabled OK OK OK

The internal reset was disabled from here on:

Full Duplex
Using an USB to serial TTL converter wired to pins 0 and 1 for TX/RX and an
external reset circuit from DTR OK OK OK
Drawing 1

Full Duplex
Keep hardwired TTL TX/RX and use HC-12 (chan 01) for the DTR to reset OK OK OK
Drawing 2

Half Duplex
Use HC-12 for TX/RX (chan 21) and HC-12 (chan 01) for the DTR to reset OK OK nop
Drawing 3

Full Duplex
HC-12 for TX (chan 41), HC-12 for RX (chan 21) and HC-12 for reset (chan 01) OK OK nop
Drawing 4

Serial settings were set to 9600 N81 for tests

HC-12 were all left at default settings, except for changing the channels

The same sketch was used for all testing
The sketch is a striped down version of my main project, send 1 byte, get a string back

A successful reset is indicated by the Pin 13 LED blinking being disrupted.

Error Messages:
Sketch uses 2836 bytes (1%) of program storage space. Maximum is 253952 bytes.
Global variables use 267 bytes (3%) of dynamic memory, leaving 7925 bytes for local variables. Maximum is 8192 bytes.
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
An error occurred while uploading the sketch

Link to HC-12 manual
http://avrproject.ru/112/rf_hc12/2016-01-14_122335_HC-12_v2.3B.pdf

The following table gives typical reference values for the various modes:
Mode FU1 FU2 FU3 FU4 Remarks

Idle current 3.6mA 80uA 16mA 16mA

Average value
Transmission
time delay 15-25mS 500mS 4-80mS 1000mS Sending one byte

Loopback test
time delay 1 31mS Serial port baud rate 9600, sending one byte

Link to Mega manual:

Rather then requiring a physical press of the reset button before an upload, the Arduino Mega2560 is
designed in a way that allows it to be reset by software running on a connected computer. One of the
hardware flow control lines (DTR) of the ATmega8U2 is connected to the reset line of the ATmega2560 via a 100 nanofarad capacitor. When this line is asserted (taken low), the reset line drops long enough to reset the chip. The Arduino software uses this capability to allow you to upload code by simply pressing the upload button in the Arduino environment. This means that the bootloader can have a shorter timeout, as the lowering of DTR can be well-coordinated with the start of the upload.
This setup has other implications. When the Mega2560 is connected to either a computer running Mac OS X or Linux, it resets each time a connection is made to it from software (via USB). For the following half-second or so, the bootloader is running on the Mega2560. While it is programmed to ignore malformed data (i.e. anything besides an upload of new code), it will intercept the first few bytes of data sent to the board after a connection is opened. If a sketch running on the board receives one-time configuration or other data when it first starts, make sure that the software with which it communicates waits a second after opening the connection and before sending this data.
The Mega contains a trace that can be cut to disable the auto-reset. The pads on either side of the trace can be soldered together to re-enable it. It’s labeled “RESET-EN”. You may also be able to disable the auto-reset by connecting a 110 ohm resistor from 5V to the reset line; see this forum thread for details.

The reset circuit for the Mega must be disabled so that the external capacitor will work. To do this, the Mega has a couple of pads just for this. They are labeled RESET-EN. Using a shape knife cut the small trace between the two pads. This can easily be solder back if needed.

I have tried many different combinations of RC arrangements for the reset circuit, with no improved results.

Somewhere I read that there are values that can be adjusted in the bootloader to lengthen the time that the bootloader is in listen mode. Have not been able to re-trace my steps to that information.

My guess is that the delay of up to 80ms per byte as shown in the HC-12 manual could be past the listen time of the bootloader, however, the Mega manual seems to indicate 500ms. (?) Drawing 5
Where can I find these adjustment values for the bootloader timing? And any other suggestions as to solving this problem.

Looking forward to some new ideas.

SKETCH

static byte count = 0;
static int CtrlByte = 0;

void SendInfoToProcess() {
// test data
Serial.print(“100,101,102,103,104,105,106,107,118,109,110,111,122,113,124,115,116,117,13.6”);
Serial.println(10); // line feed
}

void GetCtrlByte() {
if (Serial.available() > 0) {
CtrlByte = Serial.read();
if (CtrlByte == 13) {
SendInfoToProcess(); // send only after having received the ctrl byte
}
}
}

void setup() {
pinMode(LED_BUILTIN, OUTPUT);
Serial.begin(9600); //Initialize the Serial Port
}

void loop() {
GetCtrlByte();
count++;
delay(5);
if (count > 128) {
digitalWrite(LED_BUILTIN, HIGH);
}
if (count < 128) {
digitalWrite(LED_BUILTIN, LOW);
}
}

Well there is nothing like writing a forum article to make one do more research.

The problem was not timing after all, it's baud rates.

The bootloader runs at 115200, but the HC-12s were all set at 9600. Once I set everything to 115200, it works great.

Settled for half duplex, I know the range will be less, but only going for max of 150 feet.

Can upload, debug, and get data back to the Process 3 sketch.

Finally a simple wireless extension to the USB cord for remote robotic testing.

Gary Smith