PIN status while reset+flashing

Dear all,

I have a BlueTooth shell (HC-05) connected to my Pro Mini 328p. Currently it's only connected with SoftwareSerial and works very nicely, but instead I would like to connect it to the regular Arduino's TX/RX serial port in order to (additionally) be able to flash it wirelessly. And there is an additional complication: the power of the HC-05 is controlled by the Arduino itself.

If the HC-05 BlueTooth serial device was powered normally there would (probably) be no problem, just enable serial-over-bluetooth in my computer and let avrdude use it instead. But in order to save battery (I only power on the BT device every now and then and make use of the various sleep modes) the HC-05 is controlled by one of the Arduino pins (POWER_PIN) connected to the gate of a PNP generic transistor. Very neat.

So, my idea of sequence to flash the Arduino would be:

  • Set the POWER_PIN to low (to power up the HC-05)
  • Connect the computer to the HC-05 and set the serial port for avrdude
  • Do a software-reset (maybe connecting another PIN to the RESET pin and set to LOW)
  • Run avrdude to flash
  • Enjoy my new version of the code

My question (finally, sorry!) is: what would happen with the Arduino's IO pins when it resets? Because, if they change (set as INPUT or set to HIGH) during that process, the BT device will power off and the flashing will fail. Basically, the only way this can be a success story is that there is a way to set a certain pin to LOW during the whole process. Of course, if it's HIGH instead of LOW there is no problem, I will just put an additional NPN transistor and that's it.

The ideal scenario is, of course, that Arduino leaves the IO pins like they are since the reset signal until the new program begins the setup() sequence, which is good enough for me.

Any hints or ideas?

Thanks!

naevtamarkus:
My question (finally, sorry!) is: what would happen with the Arduino's IO pins when it resets? Because, if they change (set as INPUT or set to HIGH) during that process, the BT device will power off and the flashing will fail.

And that is exactly what they do on reset.

Paul__B:
And that is exactly what they do on reset.

Would you mind being a bit more specific? How do they change? Is there some sort of documentation where that's explained?
Also, if there is a very small glitch I could try putting a capacitor somewhere...

The other Paul means that outputs go back to being inputs on flash/reset. So as things stand your bluetooth module will loose power aa you feared.

One solution would be to have a pull-down resistor on your pnp base. This would mean that it would stay switched on when the Arduino pin is not set to output. Only when the Arduino pin is set to output and high would the bluetooth loose power. (You would still need a resistor to limit the base current of course.)

Paul

naevtamarkus:
Would you mind being a bit more specific? How do they change?

On reset, all registers are cleared. This included the Data Direction registers, which means that they are made inputs, and the data register being zeroed means that pull-ups are turned off.

naevtamarkus:
Is there some sort of documentation where that's explained?

Yes, it is referred to as the datasheet.

naevtamarkus:
Also, if there is a very small glitch I could try putting a capacitor somewhere...

And indeed, you might do that with a few considerations. If fitting a capacitor, you need a resistor between capacitor and transistor base, because the transistor conducts strongly at a certain threshold voltage and is current driven rather than voltage. You also need a (much lesser - 220 Ohms will suit) resistance between the Arduino pin and the capacitor to limit the current that the capacitor draws to charge. And that will slightly delay the turn-on of the controlled device.

I am glad you did not suggest a Darlington as a possibility for controlling the power of your BlueTooth.

While I was typing,

PaulRB:
One solution would be to have a pull-down resistor on your pnp base. This would mean that it would stay switched on when the Arduino pin is not set to output. Only when the Arduino pin is set to output and high would the bluetooth lose power. (You would still need a resistor to limit the base current of course.)

Saved me including that. :grinning:

That was very kind of all of you, thanks for the hints!

The problem I already see is that this is not compatible with not-consuming-anything while Arduino goes to sleep with the HC-05 off. Currently I have to spend 1mA on the gate in order to keep the HC05 running (which is more or less reasonable) but if I have to use a PULL-DOWN then I will have to spend 1mA on the gate to keep the HC05 off (my project already consumes less than 1mA while sleeping)

0.1mA would be more reasonable, but that would make me use a Darlington. Why did you not recommend it?

Another alternative would be to use some other type of PIN. Is there any PIN that stays open (OUTPUT) during flashing?

I also thought about the capacitor option, but flashing will take a few seconds and I can't think how a capacitor can keep a gate open for that long... but again, I don't know much about capacitors

Hmm... maybe a p-channel fet instead of a pnp? Then you could use a 10K pulldown, possibly higher.

Reading your original post, I'm not clear on the the re-flashing procedure. Is it entirely remote or will you intervene to press a reset button or something? If its entirely remote, what if the Arduino and hc05 are both powered down when you want to re-flash?

PaulRB:
Hmm... maybe a p-channel fet instead of a pnp? Then you could use a 10K pulldown, possibly higher.

Oh, that's a great idea indeed!! Thanks! I will certainly try it.

Yes, the idea is that the flashing is entirely remote.
The low-power concept of this project is to be in deep-sleep (POWER_DOWN + HC-05 off) most of the time, and only wake every now and then (e.g. 1h) for a few secs, just to see if the "boss" is around. The boss (actually an Android app) is smart enough to remember programmed actions and apply them when the Arduino+HC05 is around. I am close to having a fully-functional concept (with lots of bugs!) but then I thought: hey, I could ALSO flash remotely! And here we are :slight_smile:

Does it make sense?

I'm still not clear how you will get the attention of the remote circuit when you want to flash.

What do you mean by attention? You know, this is probably me being naive :slight_smile:

My intention is to put the HC05 device connected via the Arduino's Serial RX/TX ports. Once you establish a connection (from a computer) to the HC05 it creates a local serial port that you can Screen, Write or Read. My hope is that avrdude will be able to work with it.

So, if my assumption is correct, and avrdude sees this port as any other serial port (should, right?) then it can flash as if it was connected directly to the Arduino's serial port.

But, of course, the BT05 has to stay up so that the computer does not get disconnected. And if I can do it with my computer (yet to be seen!) then I should be able to do it from my Android phone.

Does this clarify your question? Please let me know if I am trying to do something impossible!

Sorry, I'll try again.

To save battery power, your remote Ardunino + hc05 spends most of its time in deep sleep (Ardunino) or powered off (hc05), correct? It wakes hourly, based on its own timer, to connect and send/receive new data.

Well, what happens when you want to flash? Chances are, you won't be able to connect, unless you keep trying over and over for an hour.

Understood... the idea is to have a service listening for connection attempts and flash if the firmware is old and it's programmed to do so.

Anyway, I think I got your point: you will be flashing (most likely) in front of the device, so you could wire a button to press and keep the HC05 on while you do it. The thing is... I will be giving the device (it's a temperature/humidity sensor) to my father as a gift, so I don't expect him to do much: just open the Android app and check the measurements. Eventually there will be a confirmation dialog asking him if he wants to upgrade to the newest firmware, and then the App will take care of it in the background when the device is available. It's a bit of an overhead for such a feature, right? But it's for fun :slight_smile: