Upload hangs if LCD display is connected to Reset pin

What may be causing such an issue?

The following is pure speculation but it may give you some hints.

I believe that the Arduino reset circuitry has undergone some changes in order to accommodate changes in the bootloader. I suspect that the recommendation to tie the two resets together may have been made when the Arduino circuitry was different and the GLCD did not upset that circuitry. Now, with the changes to the Arduino, the same GLCD circuitry could be adversely affecting the Arduino bootload process.

Don

I'm not an expert but I met one once.
I suspect that the idea to tie the resets together is to reset both the display and processor at the same time. I would think that provide the display is a "reset-not" input, line the processor, then they should be compatible.

I suspect that the idea to tie the resets together is to reset both the display and processor at the same time. I would think that provide the display is a "reset-not" input, line the processor, then they should be compatible.

I believe that all of your suspicions are correct as far as they go. With both reset lines tied together pushing the reset button on the Arduino would normally reset both device as desired and expected. You are not taking into account the bootloader and it's involvement with the reset line.

The problem is that the current Arduinos (but not the ones in use when the DFRobot documentation was prepared) have some additional circuitry that permits the serial port to automatically reset the processor as part of the bootload process. It is this circuitry, specifically the RC time constants, that is probably being upset by the presence of the GLCD.

Don

So do you think that when the DTR goes low the isolation capacitor is to small to reset both boards? That maybe the LCD board also has a pull up resistor and the two resistors in parallel provide too much pull up to be pulled down far enough or long enough by the reset circuit? I.E. the pull-up resistor on the LCD board is throwing off the RC time constant?

If this is the case then there should only be a problem when uploading a new sketch. The sketch would not upload and there will be some sort of error message. To these this, I would try manually resetting the board at the "appropriate" time. That time would be when the compile is compete and the "Uploading ..." first appears.

So do you think that when the DTR goes low the isolation capacitor is to small to reset both boards? That maybe the LCD board also has a pull up resistor and the two resistors in parallel provide too much pull up to be pulled down far enough or long enough by the reset circuit? I.E. the pull-up resistor on the LCD board is throwing off the RC time constant?

That's my thought.

If this is the case then there should only be a problem when uploading a new sketch. The sketch would not upload and there will be some sort of error message. To these this, I would try manually resetting the board at the "appropriate" time. That time would be when the compile is compete and the "Uploading ..." first appears.

That won't completely solve the problem. Any time the serial port is opened, which would include the use of the serial monitor, the problem could occur.

Don

I would think that if the problem is too much Pull-up, the effect would be to not reset the processor and/or display.

The solution might be to buffer the reset. I don't know if it will work but something like the attached schematic could work.

Buffer.bmp (17.7 KB)

What about a series diode (1N4148) between the Mega reset and the anode to the KS0108 reset line, perhaps with a 4K7 pull-up to the anode, this would prevent the KS0108 reset from affecting the board reset? While still being capable of reset by the Arduino reset, it should work just fine... IMO

Doc

ok, so here is the deal.
Some ks0108 modules don't provide a powerup reset and some do.
When Michael drew up the wiring diagram for wiring up the ks0108 for the glcd library
he recommended connecting the Arduino reset pin to the reset signal on the glcd module.
This was to compensate for the ks0108 modules that
won't self reset at power up and saved using another arduino pin to control the ks0108 reset signal.
The reset pin on the arduino board acts as an output when the reset button on the arduino board
is pressed.

Some glcd modules have powerup reset circuitry in them as well as a pullup on the glcd module reset line.
This combined with the newer auto reset circuitry on the newer arduino boards causes the auto reset
on the arduino board to fail.

It takes the combination of certain ks0108 modules and the newer arduino boards to make auto reset on the
Arduino to fail.
(Happens on newer official Arduino boards as well)

Most ks0108 modules will work if the reset signal on the glcd module is simply not connected to anything.
Of those that do not work this way, most of these will work if reset is tied to vcc.
(while you can strap the glcd module reset line directly to VCC, I'd recommend using a resistor)
For those glcd modules that still won't work, software in the glcd library can reset the ks0108 as part
of its initialization; however, in order for the software reset to work, you have to use another arduino pin.
The glcd software reset will always work for any combination of Arduino and ks0108 module but does
require using an additional pin.
To setup the library to use library controlled glcd reset you have to enable it by uncommenting the define
in the pin configuration for the ks0108 panel.
Edit your pin configuration file in glcd/config/ks0108_{board}.h and
look for the line:
#define glcdRES
Uncomment that line and use the pin number for that define to connect
to the glcd module reset line.

So you have 3 options:

  1. disconnect the reset line on the glcd module (see if that works)
  2. tie the reset line on the glcd module to vcc
  3. turn on glcd s/w control of the glcd reset line

While 1 and 2 are easier and save a pin and will work for nearly all ks0108 glcds,
in the event of reseting the Arduino the glcd module can potentially be left in an odd state and
require powering down in order to reset the glcd since there
is no other way to reset the glcd. While this very seldom happens, it is a possibility.
In other works, when not using the software reset, there is a very small possibility that when the arduino is reset
(not powered down/up) while the glcd library is talking to the glcd that after the arduino is reset
that the glcd library will not be able to properly talk to the glcd module until the arduino and glcd are power cycled.

Hope that clears things up.

--- bill

Thanks to everyone for your answers! Special thanks to bperrybap for the detailed description!

Fortunately, my display unit seems to work well without its reset pin connected to anything, so I'll leave it this way.

Indeed, "If it Ain't Broke... Don't Fix it". IMO

Doc

I noticed some further strange behavior even after I disconnected the Reset pin (also tried with it connected to +5V).

The display is connected to pins 22-34.
I upload a sample sketch from GLCD called BigNums. It works as expected. After some time I try to upload Blink basic sample and it hangs (again RX LED lights up for a while, then turns off, and then nothing happens).
After I kill avrdude.exe and try to re-upload Blink it may either succeed or fail. However if I disconnect any of pins the display is connected to (22-34) the upload will always succeed.

What can be the reason of this?

EDIT:
Looks like this is happening even if the display is not connected. Sometimes the upload will hang and disconnecting any pin (even if it is not connected with the display) seems to resolve the issue...

1nvisible:
EDIT:
Looks like this is happening even if the display is not connected. Sometimes the upload will hang and disconnecting any pin (even if it is not connected with the display) seems to resolve the issue...

"Disconnecting any pin" ? Not sure what you mean by this. Are there other things hooked up to the mega?
Perhaps there is too much load on the power supply or the AVR pins.

--- bill

Sorry for being unclear... I have made additional tests and my previous statement (the EDIT one) doesn't seem to be true.
I have my display connected to pins 22-34 and a 4x4 keypad connected to pins 36-43.
Then I upload BigNums sample.
After that I try to upload Blink sample. If it hangs, I disconnect any one of the pins 22-34 and then re-uploading seems to work. After that I connect that pin again.

1nvisible:
I have my display connected to pins 22-34 and a 4x4 keypad connected to pins 36-43.

This the first mention of additional hardware (keypad) being attached.
So there are other things hooked up in addition to the glcd.
This is why I asked about other things being hooked up to the mega.

I'm still guessing that this is due to
too much load on the power supply or the AVR pins.

This can be due to a variety of things from simple miswiring to trying to pull
too much power from an Arduino pin or the main power supply.

Do you have a voltmeter?
If so check the VCC voltage and see if it is low particularly when the upload is failing.
(this probably indicates too large of current draw somewhere, possibly due to miswiring or a short)

First I would check to see if things work with only the glcd hooked up.

Then slowly start to add the other components to see what causes the failure.

--- bill

ok,
wait a minute, the keypad is on pins 36-43?
The glcd library is using pins 36 and 37 so you have pin collision,
which has the potential to create a short.
This is very bad.
Make sure you are not sharing any pins between the glcd library and the keypad.

--- bill

This the first mention of additional hardware (keypad) being attached.
So there are other things hooked up in addition to the glcd.
This is why I asked about other things being hooked up to the mega.

Sorry for not telling this. I had some things connected to my Mega and while investigating the problem disconnected everything, but forgot about the keypad.

Do you have a voltmeter?
If so check the VCC voltage and see if it is low particularly when the upload is failing.

Am I right that I should check the voltage between +5V and GND?
If so, I don't see changes when uploading code against when the code is normally run.
When the LCD sample is on I get 4.95V.
When Blink sample is run I get 4.80-4.86V. Don't know why it drops.
Without the display I get 4.99V.
However upload hanging seems random... It may occur when GLCD is run and I try to switch to Blink while voltage is still 4.95V. It may occur when I already run Blink (after BigNums) and try to re-upload Blink (at 4.85V). It may stop occurring in the last case with the same voltage. BTW disconnecting a single pin from the display (say, pin 22) doesn't seem to change voltage, though it seems to help to re-upload sketch after upload hangs and avrdude.exe is killed (but this may be just my thoughts, however it always helped me).

The glcd library is using pins 36 and 37 so you have pin collision,
which has the potential to create a short.
This is very bad.
Make sure you are not sharing any pins between the glcd library and the keypad.

I wanted to gather all the pins used by the display and the keypad together, so I changed some constants. Here's my modified version of ks0108_Mega.h (I hope this is the only file I need to modify):

/*
 * ks0108_Mega.h - User specific configuration for Arduino GLCD library
 *
 * Use this file to set io pins
 *
 * The configuration below uses a single port for data 
 * and has the same wiring as the mega config from the previous ks0108 library 
 *
*/

#ifndef GLCD_PIN_CONFIG_H
#define GLCD_PIN_CONFIG_H

/*
 * define name for pin configuration
 */
#define glcd_PinConfigName "ks0108-Mega"

/*********************************************************/
/*  Configuration for assigning LCD bits to Arduino Pins */
/*********************************************************/
/*
 * Pins used for Commands
 */
#define glcdCSEL1     30 // 33    // CS1 Bit  
#define glcdCSEL2     31 // 34    // CS2 Bit
#define glcdRW        32 // 35    // R/W Bit
#define glcdDI        33 // 36    // D/I Bit 
#define glcdEN        34 // 37    // EN Bit

//#if NBR_CHIP_SELECT_PINS > 2
//#define glcdCSEL3     32   // third chip select if needed
//#endif

//#if NBR_CHIP_SELECT_PINS > 3
//#define glcdCSEL4     31   // fourth chip select if needed
//#endif

/*
 * Data pin definitions
 * This version uses pins 22-29 for LCD Data 
 */
#define glcdData0Pin    22
#define glcdData1Pin    23
#define glcdData2Pin    24
#define glcdData3Pin    25
#define glcdData4Pin    26
#define glcdData5Pin    27
#define glcdData6Pin    28
#define glcdData7Pin    29

// Reset Bit  - uncomment the next line if reset is connected to an output pin
//#define glcdRES         30    // Reset Bit

#endif //GLCD_PIN_CONFIG_H

EDIT:
Looks like the problem might be connected with the keypad and constants reassignment. Whenever I disconnect the keypad completely I can't reproduce the hang. Connecting pins 36 and 37 of the keypad still produces no problem (I tried multiple re-uploads). But after connecting pin 38 along with 36 and 37 I got a hang. So there must be something else I need to change in GLCD in order to use reassigned pins...

EDIT2:
I think the problem is with pin 38. If I connect the keypad without it, everything uploads fine. With it I get hangs. Does this pin have a special meaning?

EDIT3:
If I connect a wire into pin 38, upload starts hanging. If I connect that wire to GND, everything starts working. Don't understand why...

1nvisible:
Looks like the problem might be connected with the keypad and constants reassignment. Whenever I disconnect the keypad completely I can't reproduce the hang. Connecting pins 36 and 37 of the keypad still produces no problem (I tried multiple re-uploads). But after connecting ping 38 along with 36 and 37 I got a hang. So there must be something else I need to change in GLCD in order to use reassigned pins...

I'm not sure why the glcd library pins need to be changed, but what you have seems to be ok and should work.
There is nothing else to change for the glcd library to change the pins used.

Do you have a schematic of everything that is hooked up to the mega?

I'm still guessing that there is a loading issue of either the power supply or an AVR pin(s).

Perhaps the column/row lines on the keypad are mixed up or not hooked up correctly to the mega pins which is creating a short
either during scanning or when a button is pressed.
(I've seen this before)

What library is the keypad using?
Does it scan the keypad using interrupts?

Can you attached the keypad and read the keys properly without the glcd attached?
(as a test maybe do something like read the keys and send output to the serial port)

--- bill

Bill, thank you very much for your help! However it looks like the problem is unrelated to both the display and the keypad.

I disconnected everything from the Mega. Blink sample uploaded well.
Then I put a wire into pin 38 without connecting the other side to anywhere. Upload started hanging.
Then I connected that wire with GND. Upload started working again.

Could you tell me, what might be so special about pin 38?
Other pins don't seem to provoke such a problem.

Arduino mega pin 38 is AVR PD7 (port D bit 7 ) which is T0 (Timer/Counter0 Clock Input)
Not sure what is causing a problem but a dangling wire will potentially pick up noise and
oscillate the AVR pin.

--- bill