reset vs. power-on weirdness

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

I have a weird problem, from power-on my LCD screen fails to be placed into two-line mode. But after about a second the processor resets itself (the reset line is actually pulled, even though nothing else is on that line, so it's gotta be the proc, right?) and then the second line works just fine. Anyhow, if you hit the reset button, it works just fine. The internal 8mHz with 65ms delay fuse is set, and the power comes up in less than a couple of milliseconds, so it doesn't appear to be a low voltage situation. Is there anything one must do to clear garbage out from power-up? Shouldn't this sort of thing be taken care of by C? Anyone else out there see something like this?

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

Still sounds like a timing issue. Try adding a 100-200 mS delay before starting to initialize the display.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

Ya that was my first thought, to just add some more delay before calling my lcd initialization. I definitely went ahead and tried your suggestion exactly by placing 200ms delay right in front of the lcd initialization code, of course same result. So I just thought I'd go overkill and add tons of delay (like three seconds) coming right out of the gates at the start of main, then another 200ms before I go into the LCD setup routine. No luck there either. My hardware guy keeps telling me I should clear the registers on reset (he's an assembly kind of guy). However, I'm pretty certain that you can't clear certain registers without restoring the value, which would defeat the purpose of clearing them. Is this correct? Or did I miss all the tutorials where everybody learns to clear the register upon coming out of reset?

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

What registers? On the CPU? No way! They're starting up with defined values after the reset (see the datasheet).
Maybe you're writing to fast to the display? Don't know what display you're using and how you're sending data to it, but some are a bit slow and may need some delays, not only between commands, but also between toggling the various pins (if that's how you do it).
No reason why this would work after a reset and not on power up though.
I assume you ARE doing a HW reset of the display before starting to send commands?

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

It's a HD44780 compatible display (actual make slips my mind at the moment), running in 4-bit mode. And tweaking the delay values I think helped (at least it's consistently writing to two lines out of reset now, though the issue has been intermittent so my eye is still open). But it still comes out of reset and runs for just less than a second then pulls the reset line, sometimes multiple times, then it starts running just fine. Any theories on what might cause this? I'm fairly certain I'm not blowing the stack, as it runs just fine after the rocky start, but I guess anything is possible. I've also tried replacing the proc (atmega168 btw), just to make sure I hadn't blown it or something physically wrong with the chip itself.

PS - I'm glad you had the same reaction that I did at the suggestion of messing with the cpu registers(r1-r31 or something like that)

PPS - and definitely doing a hardware reset, I'm using peter fleury's lcd library, and following his example code to get everything running.

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

Hi,
Been there, done that! Ever since switching to AVR's & GCC, I have used the example code and it works! The only mods made were I do not use R/W lines and depend upon delays to ensure completion of the LCD activities.

I have had the problems that you describe at various times with other micro-controllers and have found that it is always a timing issue.

I did find that using the same code where timing was marginal, some LCD's behave differently to others and in fact there may be a temperature related issue.
The example code has not given me those problems so I will stick with it.

One long shot occurs to me that if you have a power supply with a very slow rise time, the controller may be coming out of reset before the LCD does, in which case the LCD may bot be being initialized at power up of the controller, but works OK on hardware reset. Since AVR's will work at low Vdd this may be a possibility.

Lee de Vries

Charles Darwin, Lord Kelvin & Murphy are always lurking about!
Lee -.-
Riddle me this...How did the serpent move around before the fall?

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

Your "automatic" resets after power on show that there is something else rotten.
Either YOU pull the reset line, or it should stay stable.

/Jesper
http://www.yampp.com
The quick black AVR jumped over the lazy PIC.
What boots up, must come down.

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

I am not pulling reset in the code that's for sure.

But temperature might explain the 'moodiness', but I would expect things to warm up then work fine, which isn't always the case. The internal 8mHz oscillator is temperature sensitive, correct? Has anyone ever seen a chip take nearly a full second to 'warm' up? I would've blamed the LCD before the proc, but those issues seem to have cleared by tweaking the delays. And on the power supply we checked it with the scope and it looked to be coming up pretty cleanly, I will get an exact time on how long it takes to come up next time I'm in the shop. Another thing we tried for debugging purposes was to look at MCUSR right off boot and store it in a variable so it can be thrown to the LCD after it's initialized. In one version of my code, it consistently gives external reset flag as having been thrown, however on the code where I cleaned up the display driver issues it consistently comes back with none of the flags having been thrown despite the fact reset is still being pulled low about a second after power-on. I'm pretty sure I'm not blowing the stack, but if I was would that even cause the CPU to pull reset physically on the pin?