reset via rs232

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi friends,
I'm trying to use bootloader in order to save pin count. During flashing via rs232, I have to reset MCU all time, so that I'm looking for a program that can reset MCU via rs232. My MCU is Mega8.
Is that any program to reset MCU via rs232 communication?

thank in adv,
pak

:) HAPPY AVR MICROCONTROLLER PROGRAMMING :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Most bootloaders use the watchdog to get the CPU to reset. Just enable it then sit in a tight loop without doing WDRs.

Alternatively if the bootloader hasn't enabled much of the hardware just have it put the registers it used back to the default values and JMP 0x0000 to enter the app.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can use the DTR signal line to the reset line. I show how to do this in my Virtual Serial Port Cookbook using the FT232R and C# code on the PC side. Arduino also does this. Any PC side code that writes to a serial COM port should have a function that lets you toggle the DTR line.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Joe,

What's the advantage of tying up a pin to do this? - the PC and the AVR are already communicating over a data channel so why not send it a "reset now" command and just have it watchdog?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use the DTR line as well, as far as I'm concerned, the advantage is that if you totally screw up the firmware(or the end user manages to abort the re-Flash somehow) you can still access the bootloader by exercising the reset line. The downside is that the FTDI chip seems to make the DTR line go up and down like a yoyo during enumeration(at least it does if the FTDI is setup to invert the DTR line, which mine is, for historical, lost-in-the-mists-of-time reasons).

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For a good hard reset sourced from software you can do a simple

wdt_enable(1); //enables the watchdog 
cli();//disables any interupts that could reset the watchdog
while(1);//cycles the AVR, does not reset the watchdog, and eventually the WDT resets the CPU

In the part of the code that's invoked when you want to do the reset.

There are pointy haired bald people.
Time flies when you have a bad prescaler selected.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which is great if you happen to have functioning code.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,

But that code is in the bootloader itself? If that isn't working then you are FUBAR and you have no option but to dig out the ISP programmer anyway.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Joe,

What's the advantage of tying up a pin to do this? - the PC and the AVR are already communicating over a data channel so why not send it a "reset now" command and just have it watchdog?

Cliff

In the Arduino, you write your code and press a button in the IDE to download the code. Then you press another IDE button to switch to running the code you just downloaded.

I see your point in that you could have that button send a software message to the bootloader that says 'Now switch to the application'.

This is a feature of their newest board and now I'm also wondering if it is really necessary. I'll need to investigate further since I was thinking about doing this on a board I'm designing, but now I can't see the point in it. Maybe I'm getting senile. Maybe I'm getting senile.

It is possible that they were more comfortable with a hardware fix than looking at and possibly changing the bootloader.

Smiley

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm trying to use bootloader in order to save pin count.

Let's start over from the top: One can almost always, except under the most pathological of pin assignments, do ISP on AVRs without "increasing pin count". Yes, a bit of thought is needed at pin assignment time but it usually turns out to be no biggie. There is NO reason to dedicate pins to ISP only. I'd be happy to examine the exception that proves the rule.

The question still remains: How does the bootloader get into your AVR in the first place? If ISP works once, it should work again.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pak_soft wrote:
I have to reset MCU all time

Why not fix the core problem... Why do you have to reset the MCU all the time?

I use the BLIPS bootload from stevech which works very well. At the end of programming I just hit the Exit command and the bootloader jumps back to program start 0x0000. My only comment is that it doesn't actually reset the MCU, so registers have their previous value still, but its pretty easy to reset them yourself (and should be initialised in your program anyway).

Matt

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mbotherway wrote:
...
My only comment is that it doesn't actually reset the MCU, so registers have their previous value still, but its pretty easy to reset them yourself (and should be initialised in your program anyway).

Matt

WHY? The hardware reset is guaranteed to put initializing values in the SFRegisters (like all PORT and DDRegisters going to zero, all counter/timers stopped, and so on). By depending on the hardware reset, you can often avoid quite a lot of initialization code. So why wouldn't you? Don't trust the chip to work the way it's specified to?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've noticed with the BLIPS bootloader that register values are not $00 after reset. I assume that the exit command actually just jumps to PC=$0000 which would be a software reset (not the same as a hardware reset). I will admit its just an observation, I haven't studied it very hard.

If you had WDR or some other hardware reset then I agree all values will be $00 on bootup.

Matt

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If a watchdog reset causes the bootloader to start the app, then how does the app start the bootloader?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
John,

But that code is in the bootloader itself? If that isn't working then you are FUBAR and you have no option but to dig out the ISP programmer anyway.

Cliff


No, the bootloader is in the boot section, and is protected from being overwritten. So if the end user somehow manages to remove the power during a re-Flash, it's still possible to recover by asserting the /Reset pin and thus restarting the bootloader process.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
Quote:

I'm trying to use bootloader in order to save pin count.

Let's start over from the top: One can almost always, except under the most pathological of pin assignments, do ISP on AVRs without "increasing pin count". Yes, a bit of thought is needed at pin assignment time but it usually turns out to be no biggie. There is NO reason to dedicate pins to ISP only. I'd be happy to examine the exception that proves the rule.

The question still remains: How does the bootloader get into your AVR in the first place? If ISP works once, it should work again.

Lee


The bootloader gets into the chip by being programmed into it by the distributor/supplier(along with the latest application firmware), who then send the chip to the manufacturer, who solder it onto the PCB.
The finished product has a USB(to UART bridge) connector, which is also used for various other transactions, but, by virtue of being able to /Reset the AVR via control of the DTR line, can also be employed to re-Flash in the event that there is a firmware update(extra features or bug fix) available.
I don't want to:
a) have to supply unprotected .HEX files to the end user for upgrades
or
b) have to supply an AVRISP or equivalent with every unit sold.

If you think that having the ISP pins available as well as the USB connector is some sort of improvement on this scheme, then all I can say is that you're not The Usch I thought you were.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,

I must be missing something here as I still don't get it. The way I've used bootloaders is as follows:

1) set chip so it always enters the BL at power on (in case of AVR this means the BOOTRST fuse)

2) BL looks for a "trigger" from the outside world to see if it needs to do anything special. Often this will mean looking for a specific character coming in on the UART but it could be reading an option link on an IO pin or whatever. If no trigger then check app space for presence of a valid app (maybe CRC) then either just JMP 0x0000 or WD reset to get things back to defaults.

3) If trigger then enter comms session. If instructed by PC wipe/program parts of the app session. When PC says "finished, now reset" then after CRC check either just JMP 0 or do the watchdog thing.

4) If CRC of app fails just sit waiting for inbound PC comms - maybe flash some lights to give the user a clue as to why the app hasn't started.

5) If app needs to enter bootloader then have it call a fixed entry point in the BL

So if you boot up, the PC sends a "start session" trigger, it sends "erase app" and "program app" commands but there's a power interruption or something part way through then as it comes out of the power cycle now the BL will fail the CRC test on the app and therefore sit waiting and ringing the alarm bells.

So where in all this is there a need for the PC to be able to assert the _RESET line on the CPU?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

I guess the something that you're missing is that the product I'm referring to is never powered down, and I don't really want the end user to have to remove the battery pack to achieve this, so the "at power on" concept is meaningless.
Also, maybe your programming skills are so good that you can guarantee there is no situation in which the application firmware can hang. I don't have your confidence in that respect.
I'm sure you can come up with some convoluted way to achieve everything without resorting to having the PC control the /Reset line, but what's the big deal? The FTDI chip has the DTR and RTS pins available, they're not being used for anything else and the AVR has a /Reset pin which can easily be wire ORed.
It gives me a sense of security knowing that I can always reset the AVR, in pretty much any circumstance, and while developing, I can use the same USB cable for debugging, re-Flashing and simulating button presses.
So "where is the need"? Who knows, it's certainly incredibly convenient.
Where is the downside?

John

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thanks for a lot of comments...
I found one solution that to use LPT1 to reset the MCU by ponyprog

!!! Happy New Year !!!
pak

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
So if the end user somehow manages to remove the power during a re-Flash...

If he manage to remove the power once, he should be able to manage to recycle the power again.
next
Quote:
I guess the something that you're missing is that the product I'm referring to is never powered down, and I don't really want the end user to have to remove the battery pack to achieve this, so the "at power on" concept is meaningless.

Now I am a little bit confused.
Quote:
I can use the same USB cable for debugging, re-Flashing and simulating button presses.

If you use USB cable, why you just unplug the cable and plug it back again?

I thought you are talking about underground pumps, deployed to kilometers, or traffic lights where is realy a problem to recycle the power.

Quote:
Where is the downside?

The downside is when the serial link is done by only Rx and Tx lines not a true RS232 connection. If is a long connection, with optocouplers, or it is an infrared connection or it comes from another micro on the board, it is just not resonable to add an extra line for this purpose.
And for unstable programs, the watchdog was invented long time ago.
And there is no risk for unwanted resets ?

George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Now I am a little bit confused.

Yes, you are. At least we agree on something.

Quebracho seems to be the hardest wood.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff, when you talk about check about a valid aplication firmware (CRC) you mean to check all, or only few relevant bytes ?
And how the application designer knows the key that the boot loader use if was writen by somebody else ?

George.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Has anyone kept a count of how many times the watchdog reset occurred when running well tested code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just power the AVR using the output pin of a 7555 configured as a monoshot. Every time the 7555 is triggered (use code to drive a port pin for doing that), the Vcc of the AVR will go low for the set time duration, say 1 second, then come back up. Use a load switch if you need more current capability.

If you think education is expensive, try ignorance.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:
Has anyone kept a count of how many times the watchdog reset occurred when running well tested code?

When I programmed my first system that made use of the watchdog I put a counter in. It has been running non-stop since last Feb and hasn't had a watchdog reset once.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mbotherway wrote:
It has been running non-stop since last Feb and hasn't had a watchdog reset once.
Interesting. My battery operated Butterflies without watchdogs, run until the battery runs down, and that takes years.

My wristwatch runs for years too, and I guess it doesn't have a watchdog, but who knows.

I guess if an AVR is powered by something other than it's battery, power supply glitches might affect it in ways a watchdog might cure. Strong electric or magnetic fields could do the same.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This particular system is battery powered under normal circumstances and would last around a week. However I have the test unit plugged into mains permanently. So even if our mains goes out it will run off the battery.

We had a report from a customer that one of their units was locking up and not responding after 3 or 4 days of operation. I was never able to get the same problem on the work bench (of course!), and that's when I added the watchdog in. They haven't had a problem since. I will be doing the yearly maintainance on their system next Feb and it will be interesting to check the reset counter.

No other clients have mentioned the same problem either.