Search |
 |
|
 |
| Author |
Message |
|
|
 Posted: Aug 17, 2005 - 03:15 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
Did you do as DN032 said and program the fuse bits and then the lockbits as it says
Quote:
The Boot Loader has been written for an ATmega163 with 7.3728 MHz clock. The first
time you must program the Boot Loader code into the AVR Boot Flash Section using an
external programmer. Next times, the Boot Loader enables Flash and EEPROM programming
via de UART with a PC running the AVRProg programming software.
To avoid the user can unadvisedly protect the Application Flash Section from software
updates, the Boot Loader supports neither Fuse bits nor Lock bits programming.
After programming a new ATmega163 with this Boot Loader you must program Fuse
and Lock bits as follows:
• The ATmega163 Fuse High bits must be programmed to 0x04 in order to configure
the Boot size to 256 words and to move the Reset Vector to word address 0x1f00.
• The Lock bits must be programmed to 0xEF to protect the Boot Flash Section from
unintentional changes and to allow accessing the Application Flash Section.
• The Fuse bits must be programmed before programming the Lock bits.
Please note that this is a copy and paste quote and though I am know for my typos, I did not say "via de UART".
Also, can anybody tell me what the second paragraph means? Is this Norwegian translated by Babelfish?
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Aug 17, 2005 - 04:38 PM |
|
Joined: Feb 03, 2003
Posts: 5
Location: Poland
|
|
Thank You for attention, but this wasn't the problem. I figure out that problem involves RWW section read permition. After programing device, reading of RWW section was disabled. All I need to do is to add following lines:
;-------------------------------------------------------------------------------
;L38
;-------------------------------------------------------------------------------
L38: cpi R16,'R' ;else if(R16=='R') Read program memory
brne L40
movw ZL,R26 ;Z-pointer <= address
ldi R24,(1<<RWWSRE)|(1<<SPMEN)
out SPMCR,R24
spm
which reenables reading RWW section. With this code everything works just fine (maybe there is more efficient way to do this - with code above, red lines are executed each time R command is issued).
Best regards.
-=lutecki=- |
|
|
| |
|
|
|
|
|
|
Posted: Aug 21, 2005 - 05:58 PM |
|
Joined: Aug 16, 2005
Posts: 2
|
|
Another newby with this error...
Since the posts are very recent on this matter, should I assume I won't find a solution to this problem elsewhere in the forums? I too am getting this error "Address 0x0000, Expected: 0x940c, Received 0x0100" when using AVRprog with the Butterfly. I'm new to this and have been practicing and loading small programs to the Butterfly for a couple of days with no problems. All of a sudden, I am getting this error. I've gone back, double and triple checked that I'm not doing anything different, but no success. I've tried loading programs that originally worked fine and get the same result.
Don't know if this is related but......Before the first time this showed up, I was seeming to have a communication error over my serial connection and got the error "No supported board found! AVRprog version 1.37" I eventually got it working after trying several things so I don't know what the problem was. The subject problem started the first time I attempted to load a new program. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 21, 2005 - 06:12 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
Yeah... the problem goes on. Atmel has a fellow in Norway looking into this, but so far he can't replicate the problem. The only solution I know is to reprogram the Butterfly via the ISP port. You can get an ISP programmer for about $30 bucks. If you are long term serious and commited to the AVR just go ahead and buy a STK500 $90 an you are in business, but if you are just dabbling you might consider getting another Butterfly until we figure this out.
Sorry,
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Aug 25, 2005 - 07:34 AM |
|
Joined: Aug 16, 2005
Posts: 2
|
|
Butteryfly back in business.......I'm back in business. I went ahead and purchased the STK500 since I was planning on getting it eventually anyway. I just programmed the "butterfly_app_rev06_and_boot_rev03.hex" file into it from Atmel's site and the lock bits are back to normal and the butterfly is operational.
Thank goodness there is such a wealth of information to be found in these forums. Thanks all. |
|
|
| |
|
|
|
|
|
|
Posted: Aug 25, 2005 - 03:17 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
The question that is still freaking me out is how the %#^%*#*&!! the lock bits get set in the first place. Yeah, we can fix it with an ISP programmer, but that kind of defeats the purpose of a $19.99 board doesn't it? I guess adding a $29.99 AVRISP still provides a cheap learning enviornment at 49.98, BUT, something weird is going on and who wants to use a product with weirdness built in? I guess if this was a problem with the AVR itself we would have heard about it long ago, but still, I worry.
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Aug 25, 2005 - 07:25 PM |
|
Joined: Dec 09, 2001
Posts: 82
Location: Greece
|
|
|
lutecki wrote:
I figure out that problem involves RWW section read permition. After programing device, reading of RWW section was disabled.
The problem lies in SPMCR's handling in general. You have done some serious mistakes regarding that. You need to read carefully the ATmega16 datasheet, the part about the bootloader support.
You don't follow the right steps. For example, you check for PGERS instead of SPMEN and RWW section is not treated right.
There are code examples and algorithms that will help you fix your code.
----------------------------
As for the rest of you guys, with the butterfly problem, here is my thought:
the AVRProg command for writing lock bits is ASCII 'l'=$6C=0b01101100 and since I don't own the butterfly, I took the hard way to reassemble the boot.hex file, to find out that the 'l' command is fully supported which means that when an 'l' arrives, the mega169 stores the next incoming byte to the Lock bits without asking for anything else(nor looking for framing or ather UART errors). The AVRProg (AVR910) protocol doesn't support CRC or other checking.
The 0b01101100 number seems to me an easy number to misread when a contact is loosy, don't you think?
Further more, the protocol is so simple that if the communication is lost for some reason(could be buggy bootloader like the one posted above) and a byte is lost, the bootloader will be confused and an 'l' may pass through as command, even if it is a data byte.
...You all got the idea.
However, have you really confirmed that when the 0x940C error occurs, the LockBits are set? By reading them using ISP?
You can hack the hex file by yourself and add UART error detection, or even to replace the 'l' functionality with a dummy respond, just to keep the AVRProg happy and your butterfly unlocked.
Then, if the problem happen again, well, ISP it again! 
P.S.
I don't know if it is legal to post the reassembled asm file, ReAVR is the tool.
Kyriakos |
|
|
| |
|
|
|
|
|
|
Posted: Aug 25, 2005 - 07:39 PM |
|
Joined: Dec 08, 2004
Posts: 4719
Location: Nova Scotia, Canada
|
|
|
Quote:
...replace the 'l' functionality with a dummy respond, just to keep the AVRProg happy ...
That seems like a good interim solution for a learning device -- make a replacement version of the bootloader which ignores requests to modify the lockbits. If, indeed, the problem really is that the lock bits are being inadventantly set.
In the future, if somebody goes on to produce a commerical device where lockbits are crucial, then they can spring for an AVRISP (or similar) to make sure the lock bits are done right.
But, is there another widely-available bootloader-and-PC-application pair out there which does incorporate CRCs or checksums or some other error-checking in its protocol? |
|
|
| |
|
|
|
|
|
|
Posted: Aug 26, 2005 - 05:20 PM |
|
Joined: Feb 03, 2003
Posts: 5
Location: Poland
|
|
You are right about PGERS, but what You mean by "RWW section is not trated right"? I went thru the code once again and IMHO it is consistent with AVR910 protocol, what are my serious mistakes? I'm not fluent in assembler, so any comment will be appreciated. And yes, i read datasheet carefully.
Best regards
-=lutecki=- |
|
|
| |
|
|
|
|
|
|
Posted: Aug 26, 2005 - 11:33 PM |
|
Joined: Dec 09, 2001
Posts: 82
Location: Greece
|
|
I hate hijacking other people threads, but I'll be in topic later.
lutecki:
You need to read more
The code IS consistent with AVR910(or better, the protocol in AVR109 appnote), but the DN032 and so your code are not consistent with the datasheet. The bootloader might work ok, but is is buggy!
The ATmega163 has some weirdness, unique in the AVR family.
1- He needs
Code:
.dw $FFFF
nop
after each Page Erase, Page Write, and Lock-bit Write spm instruction.
2- The RWW bits in SPMCR are not there, but some others( though compatible with the RWW bits in newer AVRs).
Anyway, the DN032 bootloader(for ATmega163) is missing:
1) the $FFFF after the spm
2) some checking for SPMEN and EEWE flags before the spm
3) application section enable after each page erase/write, using ASRE bit
4) optional application busy check(ASB flag) and then application section enable(ASRE bit) when you want to jump and execute code in application area(RWW section).
Note: The first step for the above changes is to replace the simple spm instruction with the do_spm routine, found in the datasheet. That routine's aspect is great. It assures you that the pare erase/write actions are taking place in a right manner and the RWW section is allways accessible with no risks.
The datasheet HAS all the routines you need. RTFM.
Now, for the migration to ATmega16.
The ATmega16 doesn't have the spm/$FFFF/nop silicon bug(according to the datasheet) but you can leave it, just in case. It doesn't harm anything. The steps 2,3,4 are the same, just rename the bits.
I have done the modifications of the DN032 bootloader for various AVRs(ATmega32, ATmega163, ATmega161, ATmega162[fake DT], ATmega128[you should see the mess here with the RAMPZ ]) and all work nicely but I used them only in early versions of prototypes.
[in topic]
I haven't done the UART framing error checking in these bootloaders because in my opinion, the AVRProg, the DN032 bootloader and the Butterfly are only tools for us(developers), just to show us how things work and they are not intented for commercial products. On our bench, in our home projects they work ok but that's because we know how they work and we can fix their bugs/faults.
For the development stages of a project with Butterfly you can ommit the LockBit feature, don't you think? I mean, disable it in bootloader, as I said in my first post. Then, when you have the final application code, you can put back the original bootloader and relly on Merphy's law's failure if you still want to sell it as a commercial product.
Second, if you plan to add UART error detection, the only action you are allowed to take, after the error occurs, is to ignore all next incoming chars until the AVRProg goes mad and stops sending chars. Then the user must do a manual RESET and repeat the burning proccess. Else, if you just ignore the faulty char and accept all next chars, an fatal error may occur.
Little story:
When I was modifying the bootloader for the ATmega128, I did a major mistake, I changed the previous string ["AVRB32 ",0] to ["AVRB128 ",0] but that was 8 bytes instead of 7 that the protocol supported, so the AVRProg received back 1 more char and it gone crazy. It kept sending a few commands but all the responds were shifted by 1 byte.
The bug in AVRProg is that they don't flush the UART Rx buffer before Txing a command.
That's IMHO a inoccent bug, but shows that the utility isn't professional, right?
So, my advice is to not use this kind of bootloader in any commercial product but only for our personal needs. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 01, 2005 - 02:15 PM |
|
Joined: Jun 20, 2005
Posts: 6
Location: Denmark
|
|
My story goes here:
I have recently bought a Avr Butterfly from smileymicros.com
When trying to program it via AVRprog I got the same error as many ppl in here - 0x940c
Hmm, what to do...
One of my friends had a STK500, which I borrowed to fix my problem.
After reading the "lockbits" - the result was clear. "Application Protection Mode 3: LPM and SPM prohibited" was enabled.
I tried to set it to "Mode 1", but without any luck. Erasing the device was the only option left. After the erasing, I downloaded the Bootloader from atmel at rebooted my butterfly. When reading the lockbits in Avrstudio it was "Mode 1" - perfect.
I then tried with my ordinary UART-connection via RS232. Stop, the same error again - 0x940c.
What the heck - when investigating the case closer, I discovered the lockbits was set to "Mode 3" again. I think this happened when I used the bootloader.
The problem never occurs when using the GCC-ported bootloader, because AVRStudio won't find the butterfly. When connecting from Bray's terminal I get a lot of .............. followed by a sequense of random ascii-characters AFTERWARDS I have tried AVRStudio.
Before using AVRStudio, the result is correct. The screen is filled with ??? 
I am really lost right now 
// Jacob Friis |
|
|
| |
|
|
|
|
|
|
Posted: Sep 05, 2005 - 10:03 AM |
|
Joined: Oct 21, 2004
Posts: 28
Location: San Jose, California
|
|
Hi everybody
I've been looking at this problem now and I have not been able to provoke the failure with the lockbits. If any of you users can please post a reply in this thread were you explain exactly what you did before facing the programming problem It would make the job of finding the error much easier. I'm looking for Lock bit settings, fuse bits etc..
Best Regards
Andreas Eieland
AVR Technical Support |
|
|
| |
|
|
|
|
|
|
Posted: Sep 05, 2005 - 03:35 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
Andreas,
Have you tried messing with the joystick while the bootloader is downloading code? Seems I got the idea that the bootloader might reset in the midst of a download then interpret incoming data as commands, one of which is to set the lockbits. I also wonder if something intermittent on the RS232 line or the power input (for those using external batteries) could make the bootloader forget what it's doing, and start to interpret data as commands?
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
|
| |
|
|
|
|
|
|
Posted: Sep 06, 2005 - 01:10 PM |
|
Joined: May 18, 2004
Posts: 4
|
|
Here are my experiences regarding this problem
Last time when a BF locked it self, I think my finger on the joystick trembled. One other time I had some hardware connected to port B and maybe I that way (by mistake) trigged an interrupt.
When the error occurs it always happens like this:
First I try to download code, the error message from AVRprog “No supported board found” appears. Then when I try to download code again it seams to run fine but then the error Address 0x0000…. shows.
The error happens when I use the bootloader in the hexfile “butterfly_app_rev06_and_boot_rev03.hex” It has never occurred when I use “original_butterfly_application.hex” that can be downloaded with the AVR109 Application Note. But on the other hand I have not used to many of those.
I have students that have used two rechargeable batteries (about 2,4V). They always fail. The BF always locks itself when the voltage is too low.
/Magnus W |
|
|
| |
|
|
|
|
|
|
Posted: Sep 15, 2005 - 04:18 PM |
|
Joined: Nov 07, 2004
Posts: 15
|
|
| My butterfly is brand new and I am getting this error. It is definately not the program I am trying to load. My voltage is 2.7V, I will connect a higher source to see if that helps. I do have the stk500 just not certain about how to use the stk500 to program the butterfly. Help would be great... |
|
|
| |
|
|
|
|
|
|
Posted: Sep 15, 2005 - 04:28 PM |
|
Joined: Nov 07, 2004
Posts: 15
|
|
| Update...voltage was not the issue. |
|
|
| |
|
|
|
|
|
|
Posted: Sep 21, 2005 - 09:34 AM |
|
Joined: Oct 21, 2004
Posts: 28
Location: San Jose, California
|
|
|
dblessum wrote:
I do have the stk500 just not certain about how to use the stk500 to program the butterfly. Help would be great...
Check the AVR Studio helpfiles --> AVR Tools User's Guide --> AVR Butterfly User's Guide --> Using the AVR Butterfly--> Programming.
The section contains info on both ISP and HVPP programming of the Butterfly using the STK500.
Best Regards
Andreas |
|
|
| |
|
|
|
|
|
|
Posted: Sep 21, 2005 - 02:25 PM |
|
Joined: Nov 17, 2004
Posts: 6137
Location: Great Smokey Mountains.
|
|
This just in from dblessum:
Quote:
I got lucky fixed the problem. I had AVR Studio version 4.10, I downloaded version 4.11 and installed service pack 3. This took care of my problem J. Thanks for the help, use this info for future issues…
If anyone else has this problem, then upgrades to 4.11 service pack3 PLEASE report back here as this damn problem is very hard to reproduce and we really need a fix other than reprogramming the Butterfly.
[edit] I missunderstood somebody. THIS WILL NOT FIX THE PROBLEM.
Thanks,
Smiley |
_________________
FREE TUTORIAL: 'Quick Start Guide for Using the WinAVR C Compiler with ATMEL's AVR Butterfly' AVAILABLE AT: http://www.smileymicros.com
Last edited by smileymicros on Sep 22, 2005 - 05:27 PM; edited 1 time in total
|
| |
|
|
|
|
|
|
Posted: Sep 22, 2005 - 01:02 AM |
|
Joined: Sep 22, 2005
Posts: 4
|
|
Hi - I have been in communication with Joe, and at least in my case, I started with the AVR Studio 4.11.410 SP3, worked successfully with the Butterfly over the serial interface for a few weeks, then got into the lock-up state a few days ago.
So while it is still plausible (but unlikely) that upgrading from 4.10 to 4.11 fixes the problem, it appears that simply using 4.11 is not a fix. However, as Joe indicates if anyone corroborates that the upgrade process is the key to unlocking the Butterfly, we'd love to hear about it.
Note that I was using the Butterfly with 2 x 1.2v rechargeable NiMH AAs. If the lockup is voltage related, I may have been pushing the envelope here. (Although it worked great for a few weeks).
-h |
|
|
| |
|
|
|
|
|
|
Posted: Sep 22, 2005 - 12:06 PM |
|
Joined: Oct 21, 2004
Posts: 28
Location: San Jose, California
|
|
Hi guys!
On the voltage issue, please note that the voltage operating range for the mega169V placed on the AVR Butterfly is 1,8-5,5V. If your batteries are close to empty (and you have changed the BOD settings) programming of the device might be unsuccessfull leading to unpredictable behavior.
A nice tip is to always remove the battery when not using the device .
Best Regards
Andreas |
|
|
| |
|
|
|
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
