Forum Menu




 


Log in Problems?
New User? Sign Up!
AVR Freaks Forum Index

Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Author Message
braddock
PostPosted: Aug 17, 2009 - 05:51 AM
Newbie


Joined: Sep 17, 2007
Posts: 15


_delay_ms defined in util/delay.h seems to consistently hang on me for delay values greater than 10ms, and sometimes across multiple calls with values of 10ms.

Let me lay it all out so someone can tell me if I'm doing something really dumb.

Hardware: Uzebox AVCore w/Atmega644
F_CPU=28.636360 MHz

Simple code to demonstrate problem:
Note, I am looking on PA3 with an oscilliscope, and uncomment "GotThisFar()" to see if the code gets far enough to put out a signal.

Code:

#include <avr/io.h>
#include <util/delay.h>

#define DDR_OUT DDRA
#define PORT_OUT PORTA
#define PIN_OUT PINA
#define POUT PA3

void GotThisFar() { // put a signal on my scope
  while (1) {
    PIN_OUT |= 1 << POUT; // toggle
    for (int j=0; j<30000; ++j); // delay
  }
}

int main() {
  DDR_OUT |= 1 << POUT;
  //GotThisFar();  //YES
  _delay_ms(1.);
  //GotThisFar();  //YES
  _delay_ms(1.);
  //GotThisFar();  //YES
  _delay_ms(10.);
  //GotThisFar();  //YES
  _delay_ms(10.);
  //GotThisFar();  //NO
  _delay_ms(11.);
  //GotThisFar(); //NO
  _delay_ms(20.);
  //GotThisFar();  //NO
  _delay_ms(1000.);
  GotThisFar();  //NO

  while (1);
}



Compilation commands:
Code:

avr-gcc -o build/avr/scratch/z816c-delay.o -c -std=c99 -ggdb -Winvalid-pch -Wall -Wno-long-long -pedantic -Os -mmcu=atmega644 -ffunction-sections -fsigned-char -DF_CPU=28636360UL -Ibuild/avr -I. -Ibuild/avr/scratch -Iscratch -Ibuild/avr/scratch/-I/usr/local/avr/avr/include -Iscratch/-I/usr/local/avr/avr/include scratch/z816c-delay.c
avr-gcc -o build/avr/scratch/z816c-delay -mmcu=atmega644 build/avr/scratch/z816c-delay.o
avr-objcopy -O ihex -R .eeprom /mnt/data/home-z5/braddock/Private/work/tviki/tviki/build/avr/scratch/z816c-delay /mnt/data/home-z5/braddock/Private/work/tviki/tviki/build/avr/scratch/z816c-delay.hex


GCC AVR toolchain as built and patched by the Bingo script as of last week on Ubuntu 9.04. gcc version 4.3.3 (GCC) GNU assembler version 2.19.1 (avr) using BFD version (GNU Binutils) 2.19.1 + coff-avr-patch (20050630).

I'm relatively new to AVR, but have spent a few hours tracking this problem and something seems off.

I found that if I replace the inner loop _delay_loop_2() assembly code with a simple C "for" loop, then the _delay_ms function never hangs.

Any help appreciated. Thanks!
 
 View user's profile Send private message  
Reply with quote Back to top
mtaschl
PostPosted: Aug 17, 2009 - 06:03 AM
Resident


Joined: Aug 21, 2002
Posts: 896
Location: Austria

Quote:
F_CPU=28.636360 MHz
Running a 20MHz chip at 28MHz is no good idea...

_________________
/Martin.
 
 View user's profile Send private message  
Reply with quote Back to top
Koshchi
PostPosted: Aug 17, 2009 - 06:42 AM
10k+ Postman


Joined: Nov 17, 2004
Posts: 14662
Location: Vancouver, BC

The maximum value for _delay_ms and still get the highest resolution is 262.14 / F_CPU_in_MHz. For 28.63636MHz that would be 9.154ms. Anything higher than that and the macro uses a double loop (basically calling _delay_ms multiple times with a smaller value). There might possibly be a problem with that part of the macro.

_________________
Regards,
Steve A.

The Board helps those that help themselves.
 
 View user's profile Send private message  
Reply with quote Back to top
dl8dtl
PostPosted: Aug 17, 2009 - 09:26 AM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7365
Location: Dresden, Germany

> There might possibly be a problem with that part of the macro.

Though personally, I've never observed it to fail. I use longer
delays quite frequently in simple ad-hoc applications.

I'd also expect the 40 % overclocking to cause trouble.

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
braddock
PostPosted: Aug 17, 2009 - 02:21 PM
Newbie


Joined: Sep 17, 2007
Posts: 15


Okay, I am definitely ready to blame the hardware and/or Uzebox's overclocking.

I woke up this morning and ran the exact same tests and my app on a cold board, and no more problem. Last night the board had been running all day.

Can these little chips overheat easily?

When it happens again I'll try using the clock pre-scaler.

I have been observing other inconsistancies with the Uzebox AVCore board since I started AVR work two weeks ago. I had through it was just because I was a newbie or maybe the toolchain stunk, but perhaps not.

As an additional datapoint, I tried replacing the _delay_ms function with a trivial assembly loop and was having the same hanging problem. So it does not seem to be a problem with _delay_ms()'s resolution logic.

What is the "real mans" dev board for 20 MHz ATmega644? Uzebox is proving to be a poor environment.
 
 View user's profile Send private message  
Reply with quote Back to top
stu_san
PostPosted: Aug 17, 2009 - 04:03 PM
Raving lunatic


Joined: Dec 30, 2005
Posts: 2327
Location: Fort Collins, CO USA

braddock wrote:
Can these little chips overheat easily?
Define "overheat". Meaning enough to cause failure? In normal applications and at rated clock speeds, no. Overclocking the hell out of the chip (40% overclock qualifies for this description), probably. The danger of overclocking always comes back to heat, since heat causes the transistors in the chip to slow down and since power ("heat", sorta) is related to the frequency of the signals driving each of the nodes in the chip. That's also why "pro" overclockers use liquid nitrogen to improve their performance - cooling the chip will improve transistor performance and thus allow higher clock rates.

braddock wrote:
What is the "real mans" dev board for 20 MHz ATmega644? Uzebox is proving to be a poor environment.
Arduino? (No, that seems to be either m168 or m328)

AVR Butterfly? (No, that's an m169). A

VR Dragon? (No, that's limited to devices with 32K of flash or less).

AVR STK500? Yes, that supports everything but it is (relatively) expensive ($78 at Digikey - not bad. You might find a deal - eBay and suppliers that bundle it with other things come to mind). Check for the pin count, since the Mega644 may need an adapter card (STK501/502/...) which adds another $78-90 to the cost.

Other suggestions? Dunno

Stu

_________________
Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!
 
 View user's profile Send private message  
Reply with quote Back to top
theusch
PostPosted: Aug 17, 2009 - 04:25 PM
10k+ Postman


Joined: Feb 19, 2001
Posts: 28194
Location: Wisconsin USA

Quote:

braddock wrote:
What is the "real mans" dev board for 20 MHz ATmega644? Uzebox is proving to be a poor environment.

Some are partial to the ERE board. I don't know if it has provisions for the second USART.
http://www.ereshop.com/index.php?main_p ... cts_id=181

Let's check Sparkfun for Olimex 40-pin:
http://www.sparkfun.com/commerce/produc ... ucts_id=32
http://www.sparkfun.com/commerce/produc ... ucts_id=31
http://www.sparkfun.com/commerce/produc ... cts_id=474
 
 View user's profile Send private message  
Reply with quote Back to top
dl8dtl
PostPosted: Aug 17, 2009 - 04:36 PM
Raving lunatic


Joined: Dec 20, 2002
Posts: 7365
Location: Dresden, Germany

Btw., I don't think the real problem with overclocking an AVR is
caused by overheating. The limiting factor is the flash read speed,
and if you go dramatically beyond the guaranteed limits, your
application will simply start reading nonsense out of the flash.
That might be affected by a temperature rise caused by heating up
the chip, but in that case, you're already well beyond the safe
flash read speed anyway.

_________________
Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.
Please read the `General information...' article before.
 
 View user's profile Send private message Send e-mail Visit poster's website 
Reply with quote Back to top
braddock
PostPosted: Aug 21, 2009 - 05:35 AM
Newbie


Joined: Sep 17, 2007
Posts: 15


To keep the thread up to date: I have encountered this board anomaly a few more times.

I have, for example, a piece of code now running perfectly at 14MHz using the clock pre-scaler that hangs consistently at 28MHz.

Worse, it is code which ran at 28 MHz last night - the effect is not constant - I think it has to do with how long I power the board (doing dev for many hours at a stretch).

So the evidence mounts that this is an over-clocking/heating issue.

I don't know if I just got a bum chip set or if this is endemic among the AVcore Uzeboxen.

An STK500 w/20MHz crystal + JTAG emulator are in the mail. Smile

Thanks for everyone's help,
Braddock Gaskill
 
 View user's profile Send private message  
Reply with quote Back to top
ccowgill
PostPosted: Aug 21, 2009 - 08:00 AM
Newbie


Joined: Sep 03, 2008
Posts: 11


braddock wrote:
To keep the thread up to date: I have encountered this board anomaly a few more times.

I have, for example, a piece of code now running perfectly at 14MHz using the clock pre-scaler that hangs consistently at 28MHz.

Worse, it is code which ran at 28 MHz last night - the effect is not constant - I think it has to do with how long I power the board (doing dev for many hours at a stretch).


Hey Braddock,

I did the hardware design on the AVCore, so I have a couple thoughts for you. Firstly, the AVCore and the Uzebox project in general are really centered around generating full color video and high quality audio for games/guis/etc. We do overclock the crap out of the '644 to get the cycles necessary for running the Uzebox kernel and doing on the video/audio/etc. on the fly directly with the CPU. (That's described on the Uzebox website and in Sparkfun's ad copy though, so I'm sure you knew all that already-- I'm just posting that to clarify to anyone else reading!)

If you *don't* need the video generation/sprites/scrolling/digital audio support from the Uzebox kernel then there's really no need to run an overclocked part. As you discovered you can run the AVCore with the clock prescaler at 14.318MHz or, if you like, replace the crystal on the AVCore with something within spec. That way you still get the 'all in one' module with the microSD, IO's, etc. If you try to run video at the slower (or just different) clock speeds you have to do a lot of rewrite in the Uzebox kernel though. It's rather hardwired for the 28.636MHz... Lots of cycle counting assembly in there. Wink

That having been said-- not all '644s run at the overclocked rate. Both Limor (LadyAda has her "Fuzebox" varient) and I have been screening the parts we use and some *do* fail testing. CPU's with problems will generally show issues with the video generation immediately (since even just one bad fetch is enough to skew the video and cause sync problems). I've not heard of any potential field failures before yours though, so I think the screening works well all in all.

I'd be surprised if heat were an issue unless there was a cold solder/fractured joint on the package that was messing with power/ground integrity to the '644. I think the most common failure is due to flash access speed, although Uze (the fellow that did the Uzebox kernel) reported a skittish UART on one of his early prototypes. (Wire-wrapped protoboards were not ruled out in that case however.)

Have you tried reloading the "ESD Attack" .hex file to the AVCore and see if it plays properly-- if not then it's definitely an AVCore problem. If it *does* work though, then that's a little suspicious. (That's a lot of code to be working properly while your short test fails... I agree that it sounds like a hardware issue at this point, but it might be worth a test.)

Another thing to try is a different power supply (or adjust your power supply output level if it is tweakable). Voltage (and a clean power rail) is much more critical with an overclocked part than one run entirely inside the safely spec'd numbers on the datasheet.

If you want, get in touch with me (my email address is on the AVCore schematic, or message me on the Uzebox forums) and I can swap you out for a new module if you want to just try a different one (I'd hate for you to have bought it and not be able to use it!). If nothing else I'm curious to see the 'bad' module and figure out the root cause as best I can. Smile

-Clay
 
 View user's profile Send private message  
Reply with quote Back to top
braddock
PostPosted: Aug 23, 2009 - 02:25 AM
Newbie


Joined: Sep 17, 2007
Posts: 15


Hi Clay et al.

I discovered a mea culpa factor today while studying the Uzebox AVCore schematic.

I had checked before that the board had a regulator on it, but I hadn't realized until today that the regulator is _ONLY_ used for the SDCard, and the AVR is being powered off of _raw_ 5V from the power plug with no additional regulation.

I've been using an unregulated power supply, so I am out of spec.

Looking back I see that this is noted at the bottom of the SparkFun production description. I must have missed it.

I'll have to dig up and test using a regulated supply.
 
 View user's profile Send private message  
Reply with quote Back to top
ccowgill
PostPosted: Aug 29, 2009 - 03:46 AM
Newbie


Joined: Sep 03, 2008
Posts: 11


braddock wrote:

I had checked before that the board had a regulator on it, but I hadn't realized until today that the regulator is _ONLY_ used for the SDCard, and the AVR is being powered off of _raw_ 5V from the power plug with no additional regulation.

I've been using an unregulated power supply, so I am out of spec.


Ahhh, yeah, that could definitely have an impact. You pretty much need the 5V rail to run overclocked. (Some parts work fine at 3.3V @ 28.636MHz, but it seemed like a lot of them really needed ~3.4V amusingly enough.) Wink

I decided to just release it as the 5V version rather than risk problems.

The "gamer baseboards" that I sold originally had a Schottky in series with the power input to prevent reverse polarity power supplies from causing damage, but then I shipped those with 5.5VDC wall-warts to make sure there was a solid 5V+ at the module. (The video resistors, etc. are also setup for 5V.)

The SparkFun version baseboards just use a 5V regulated supply directly into the board. (They wanted to use the same supplies they stocked for other products.)

Yell if you still have problems...

-Clay
 
 View user's profile Send private message  
Reply with quote Back to top
Display posts from previous:     
Jump to:  
All times are GMT + 1 Hour
Post new topic   Reply to topic
View previous topic Printable version Log in to check your private messages View next topic
Powered by PNphpBB2 © 2003-2006 The PNphpBB Group
Credits