[SOLVED] Uncontrolled behaviour while compiling

I reduced my program to some basic intructions, and even there is a problem while uploading! The relay/bell is activated while uploading. It looks that the output doesn’t behaviour as a tristate.

//Processor Arduino Nano V3
//Compiler Arduino IDE ATmega328P (Old Bootloader)
const byte Bellpin = 4 ;

//==========================================================
void setup(){
  Serial.begin(9600);
  pinMode(Bellpin, OUTPUT);    // sets the digital D4 (pin 7) as output
  Serial.println (millis());
  digitalWrite(Bellpin, LOW);
  }

//===========================================================
void loop() {
  if ( millis() >= 10000 && millis() <=  12000) 
      {Serial.println (millis());
        digitalWrite(Bellpin, HIGH); }
      else 
      {digitalWrite(Bellpin, LOW);}    
   }

As 6v6gt said: without a good solution I have to integrate a switch in the outputline.

Is there any difference if you write a LOW to D4 before the pinMode?

Have you tried a sketch that does not use D4 at all, to see if it is something in the bootloader itself?

Well, I have just tried uploading that sketch, using a USB cable, to a fresh Nano (ATmega328p) with standard fuse settings, which has the the old boot loader on it and measured pin D4 with a volt meter. Unsurprisingly, it didn't show anything until after the 10 seconds had expired.

I can only guess that you have a faulty Nano or the wiring around it is faulty (somehow).

Can you verify that the schematic is correct, and the 560 ohm resistor goes to ground,, as well as the Arduino, the SSR, and resistor share a common ground?

I measured some voltages on output D4:

USB-supply external 5 V supply
During upload 1,87 V 2,14 V
low state 0,22 V 0,254 V
High state 4,42 V 4,70 V

The output voltage during upload is enough to "fire" the SSR; the specified input voltage range of the SSR (Crydom MP240D4) is 3-32 Volt.
It wondered me!

Finally I fixed the problem by putting 2 diodes in series in the outputline.

Thanx to everybody fot thinking with me!

Good that it is fixed but with two series diodes followed by a 560 ohm sink, there is not going to be much left to drive the led in the SSR.
Did you make the during upload voltage measurements with pin 4 completely disconnected from the SSR and resistor circuit or was all that still connected?
I can’t reproduce this spurious voltage during upload so I guess it is something specific with your environment.

Herewith the final scheme for the output part.

Have you tested using a different pin on the Arduino instead of D4? That really sounds like a hardware problem, the pins should be in input mode without the internal pullup except for those used by the bootloader (pins D0, D1, and D13).

I found two other items regarding the same problem (digital IO during startup).

Now the question: which ouput pins of my Arduino Nano V3 should I avoid?

ArduinoStarter1:
I found two other items regarding the same problem (digital IO during startup).

Now the question: which ouput pins of my Arduino Nano V3 should I avoid?

Pin D13 because it is used by the bootloader to flash the internal led-
Pins D0 and D1 (RX and TX) because these serial pins are used during the upload process.

I can't explain pin 4 being pulled high during program upload. From the code you have supplied, it appears that pin 4 does not have the pullup enabled. However, there are subtle things you can do which have the effect of turning on the pullup resistor such as setting a pin to HIGH before the pinMode() call or, maybe, setting a pin state in a class constructor method, since these are invoked before setup(). If the pullup resistor is enabled, that might allow enough current to switch the LED in the SSR.

A side effect of a direct port write operation, maybe in a library function, could also be a possible cause. Maybe attach your entire sketch.

Hallo 6v6gt

I disabled the pulllup resistor (digitalWrite(Bellpin, LOW); // disable internal pullup) in row 132.
Unfortunately without success.

My intention is to solve the problem by software (without diodes in the output line).
Otherwise I think to use a time delay relay with reed relay to prohibit the output pulse during the load process.

Enclosed my complete code

Slagwerk_20d.ino (30.3 KB)

On closer look, I see nothing to explain this.

Going back to post #10 where you have a very simple sketch which exhibits the same problem, did you observe the same behaviour with that nano out of the circuit ? In principle, apart from the pins previously mentioned, all pins are in a high impedance (floating) state during the upload process.

In your main sketch, you are using the String class which is always a discussion point when unexpected behaviour is exhibited but, of course, that does not apply to the post #10 sketch.

I'd start with a the post #10 sketch on a replacement Nano, out of circuit, and start from there.

Did you mean to make the condition of the if statement an assignment instead of a comparison?

      //condition to strike the hammer
      if (blnBellCycle = true) {  // << this assigns the value 'true' to blnBellCycle
        //Calculate the number of Pings
        if (hour == 0) {
          hour = 24; //Midnight is presented as 0:00, but the bell has to ring 12 times
        }
        if (hour >= 1 and hour <= 12) {
          numberPings = hour ; //Fix number of beats for hours
        } else {
          numberPings = hour - 12;
        }
        if (minute == 30) {
          numberPings = 1; //One beat for the half hours
        }

Yes David_2018,
the clock runs from 00:xx upto 23:xx; the number of pings runs from 1 to 12.

But I want to focus to the short moment that the output goes high during uploading.

This

if (blnBellCycle = true) { // << this assigns the value ‘true’ to blnBellCycle

is not the same as

if (blnBellCycle == true) { // << tests the value blnBellCycle

the first (assignment) if statement condition is always true, the result of the assignment.
the second (== test of equality) controls whether the body of the if statement gets executed.

So “=“ looks odd in this circumstance, and will generate a warning since it is a common
mistake and uncommon if legal and arguably useful.

More readable code probably avoids assignment within the condition part of an if statement.

So when your focus returns to why something isn’t working the way you thought, you might look at that again first.

a7

Can you remove the Nano and see if the SSR remains off? This still seems like a hardware problem. Did the Nano come with pins/headers soldered on, or did you install them yourself?

Are you able to post some good resolution photos of the wiring and/or pc board? If pin 4 on the arduino is not damaged, then I would suspect leakage current somewhere in the SSR circuitry, some error in the grounding, etc.

The SSR works in the normal operation mode fine (all connected pins work good / yes self soldered)).
The problem is the status of the IO-pins during uploading.

Mostly the output has to zero (the church bell is not ringing).
After (a simulated) grid faillure the Arduino Nano will reboot and comes for a short while with a HIGH signal.

ArduinoStarter1:
. . .
After (a simulated) grid failure the Arduino Nano will reboot and comes for a short while with a HIGH signal.

This is not quite the same thing as instability during software upload which is what I understood originally.
This could be something in setup(), for example attaching an interrupt when an interrupt is already pending, a counter being reset to 0, or something similar. All this can be tested by simply pressing the reset button and see how it behaves.
Again, the simpler the test which demonstrates the problem, the simpler the problem analysis.

There are some other issues which I've just noticed in your main sketch:

cnt1 is set in an ISR so should be declared as volatile. The same with blnShowDateTime and blnOnTop.
Serial.print() also does not function reliably in an ISR.

ArduinoStarter1:
The SSR works in the normal operation mode fine (all connected pins work good / yes self soldered)).
The problem is the status of the IO-pins during uploading.

I'm not questioning the operation of the SSR during normal operation, at that point D4 is in output mode and actively driving the SSR. The problem appears to occur when D4 is in input mode, implying something is supplying current to the SSR at that time, and for a sufficient length of time to be noticeable.

Does the SSR turn on if you upload the example Blink sketch, code that should never do anything with D4?

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.