0x940c in AVRProg error message - bootloader confusion?

Go To Last Post
192 posts / 0 new

Pages

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

Thanks Steve, but I was looking for a link to the new BootLoader from ButterFly/AVR Develpment team. They also wrote a new one.

But thank you anyhow for your help.

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

Okay, sorry. I will look around. I remember seeing the announcement from Atmel.

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

How about the 13th post down from the top of the ninth page of this thread. Sorry, I don't know how to do the hyperlink (or whatever it is called) thingie. If that doesn't work try a search on member "eieland" (without the quotes). He/she only has 13 posts so it shouldn't be but so hard to find that post.

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

Okay, thanks Steve, I Just downloaded it.

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

That would be back on the previous page, page 9. Have a look near the very bottom for the post.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

... or, at the excellent Smiley's Butterfly 0x940C error summing-up, here: http://www.avrfreaks.net/index.p...

Dear RetroDan, the latest release is the "ButterflyBoot v1.1L.hex", which has the Lock-bits writing feature enabled.
There have not been any misbehaviour reports yet...

George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Okay, I have ButterFly locked up again!
Please, no Flames this time!
I'm trying to be helpful...read on.

I'm either the owner of some very "touchy" BFs or my setup here is problematic. The DB9-DB9 cable I am using is rather long and looks fairly thin so I don't think there's much sheilding. I have four computers side-by-side and at times the monitors interfere with each other, so there's a lot of EMF. I also have Flourescent Lights which make some circuits go crazy. So to put a fine-point in it -- I glow in the dark.

This seems to point to the possibility that garbled xmission of data is probably the main culprit. I get a lot of BF lock-outs.

I don't know much about fuses and locks yet, but as promissed I am going to enter the data as read from a "locked" ButterFly using Dean's excellent ButtLoad program loaded into another ButterFly. (I have not setup my STK500 yet).

I hope you find this information useful and would appreciate feed-back

-------------------------------------------------------------------------------------------------------
AVRISP:
Entering programming mode... OK!
Reading fuses... 0xFF, 0X98, 0xE2... OK!
Leaving programming mode... OK!

LOCKBITS: (These are the ones shown with a check-mark)
[v] Mode 1: No Memory Lock Featured Enabled
[v] Application Protection Mode 3: LPM & SPM prohibited in app sec
[v] Boot Loader Protection Mode 1: No lock on SPM and LPM in Boot Loader
(No other Lockbits show checkmarks)

FUSES:
[v] Brown-out detection disabled
[v] JTAG Interface Enabled (JTAGEN=0)
[v] Boot Flash section size=1024 words @ $1C00
[v] Boot Reset vector Enabled (def addr=$0000)
[v] Int RC Osc; Start Time 6 CK + 65 ms
** In Addition Fuse Marked "Serial Program Downloading (SPI) enabled (SPIEN=0)
is filled-in with grey color and a RED Question mark[?}
(No other Fuses appear to be checked-off)
-----------------------------------------------------------------------------------------------

Which are the problematic Fuses/LockBits?

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

I would imagine:

Quote:
[v] Application Protection Mode 3: LPM & SPM prohibited in app sec

That's stopping the bootloader from writing new data to the application flash space. When you unlock the Butterfly, can you follow the sequence I posted earlier, loading in the bootloader into ButtLoad's storage and then reprogramming the locked butterfly via that? I'd be interested to see if it works...

- Dean :twisted:

PS: ISP fuse is disabled (gray box) because you cannot use the ISP interface to disable itself for safety reasons.

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Okay what I did was restore the locked ButterFly to the original program that was shipped with these units when new, then went into AVRISP and read the Fuses and LockBits and the only difference appears to be with the LockBit:

[v] Application Prot Mode 1: No Lock on SPM....

So it would appear that this LockBit took the Functioning ButterFly from App Protection Mode 1 to App Protection Mode 3.

Is that inline with everyone's assumptions?

I'm to "burn" GeoLoad Version 1.1(L) from Giorgos Next and test it.

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

Okay Giorgos. The ButterFly locked up after just a few attempts.
I seem to have the "perfect" setup for making these things fail.

I just re-read the setting with AVRISP and the only change again appears to be
the change in LOCKBITS from Mode 1 (No Lock) to Mode 3 (LPM & SPM prohib...)

I hope you find this info useful. Is there anything else I can do to help you nail-down the problem?

I also noticed that it had "problems" starting my little program.
Is there a difference in the start-up sequence between GeoLoad and Original Software BootLoader? I'll try to describe... with original SW after I loaded my program I hit nailed RESET pin and press Joystick and my program starts no problem.

With the GeoLoad V11(L)I would have to RESET CHIP several times and press Joystick up before I could get program to start up.

Please understand that I am in no way complaining at this point, I'm only trying to be helpful. If you would prefer we could take this to private mail(?)

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

Dean I am trying to locate those instructions.
Also, is there anything else I can do before I restore this locked BF?

If all I'm using is the PC Serial/DB9 and the UART set-up as described in the ButterFly Documention using "AVR Prog" there is no way that any of these BootLoaders should allow me to change any of the fuses or lock-bits, on my own correct?

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

Hi RetroDan. I was going to ask you what bootloader did your Butterfly have, during the lock-up, but you have already answered this to me!

Of course I use a different approach! Let me look at this, though I have not received yet my Butterfly unit, to experiment on the real hardware. Until then, you can use the failsafe "ButterflyBoot v1.1.hex" firmware, that does not have the Lock-bits writing feature enabled.

I guess that we should continue the debugging at the dedicated enhanced Butterfly bootloader thread: http://www.avrfreaks.net/index.p...

Thanks for the feedback,
George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

If it is any help what I did was dump the contents of "Locked" ButterFly which has your GeoLoad v1.1L and my little program to a Hex file (45K) would that be any help to anyone? Can you re-load it and disassemble it to see what the problem might be?

You say the previous GeoLoad V1.1 has the writing feature totally disabled? Okay I'll try that one next.

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

If the FLASH-dump has been generated using the bootloader, it is useless bacause a locked FLASH will report pseudo-random memory contents.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

The dump was done using Dean's ButtLoad acting as an AVRISP device connected to the problem ButterFly. Would that HEX dump be of any use?

If not, can I unlock something to get a better HEX Dump?

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

RetroDan,

Have you used an ISP programmer to load the older version of the bootloader from: http://www.siwawi.arubi.uni-kl.d...

And, if you did load that bootloader did the failure give you the 0x940c in the error message?

Smiley

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

Older BootLoader? No Sorry, let me explain...

When this problem first appeared and I was down to my last functioning (and unused)
Butterfly I used the SAVE PROGRAM feature inside AVR Prog and dumped it's contents to a HEX file then went out on the Internet on my wild escapade looking for a solution; which after a few days led me here. I did NOT want to screw-up my last remaining BF.

So after getting Dean's ButtLoad program into the "Virginal" ButterFly (as that was the only one I could still program) he was kind enough to walk me through the procedure of reprogramming the "Locked" BFs by using the AVRISP feature of his software.

Since that time, whenever a BF "Locked" I would grab this "Extra" BF with ButtLoad on it and quickly re-program it using the HEX dump from the Virgin BF. I did NOT switch to the older BootLoader.

Now that there are 2 more BootLoaders: Giorgos' ASM version and the "Official" new version from AVR -and- since I seem to some "quirk" in my setup here that seems to be able to force these things to fail on a regular basis, perhaps it's an excellent way to test-out these new versions.

I'm trying Giorgos' GeoLoad 1.1 version at the moment. If it lasts more than a day, then I would declare it a success as even on the best of days, I seem to be able to get a failure within a few hours and sometime after just 2 or 3 "burns."

I hope this information is useful and if anyone thinks it will spark another flamewar, I'd be glad to move to private mail.

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

Dan,

Just a small point but you also have an STK500 don't you? Rather than trying to juggle the Butterflys wouldn't it just be easier to ISP all three back to default (but maybe with Giorgos' new bootloader) using the STK500 ?

Cliff

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

I would appreciate it if you could get the old bootloader from: http://www.siwawi.arubi.uni-kl.d... and download it to your failing Butterfly using Dean's ButtLoad and see if that older bootloader is also failing. The reason I ask is that this is the way I've been recommending that folks fix their 0x940c problem and it was the basis for Atmel's decision to change the bootloader on the next batch of Butterflies. If you do have a case where this fix doesn't work, then we need to know if your situation is a special case or if we haven't actually solved the problem. I suspect that yours is a special case since I've put the old bootloader on a number of Butterflies and not had the 0x940c problem return.

Also, in these more recent failures you've experienced, did you get the 0x940c error?

Thanks,
Smiley

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

Cliff, been so busy playing around with ButterFlies (they really are cool!) that I just have not got around to setting the STK500 up, but I will.

Smiley, Okay now I understand. Good thinking. I seem to have an unusual situation here so lets make the best of it.

BTW - I have just had a version of Giorgos' GeoLoad 1.1 FAIL on me.
The error is 0x6246 instead of the 0x940c

Just for the sake of clarity, that means that BOTH the Giorgos' BootLoaders have failed.

The 1.1 version AND the 1.1(L) version.

I will next try following the above link and try the older version of the BF/BL next.

TTYL

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

Smiley, I need help.... I see three BootLoaders at that link.

1) ABR ButterFly BootLoader - Code port to avr-gcc
2) AVRPROG (AVR910) compatible BootLoader
3) BootLoader compatible with STK500

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

Geez, there's all sorts of version at that link.

I really want to help if I can. How about you UPLOAD the exact version you want me to test as a HEX file right here and now(?)

That way if it fails there will be no confusion about which one I was actually using.

Sound good?

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

He it is.

If AVRFreaks is still having the download naming problem it may appear as index.php, just rename it bfboot.zip and opent it.

Smiley

Attachment(s): 

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

Okay I just DL'd it.

I have been using the NEW Official BootLoader from AVR and I have been unable to make it "Lock-Up."

I will switch to this "Smiley" Version right now.

BTW - DL Files are renamed index.

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

If the new version works, then we have our solution, no need for further tests.

Smiley

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

Oh Geez, thanks, after I just switched....

Okay, I will revert to the NEWEST version of the OFFICIAL BootLoader.
And continue testing that one.

BTW - So far neither the "Smiley Version" or the Newest Version have failed yet.

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

Hello guys,

I just ordered my BF today from digikey, I will take some time to see if I can have the same problem as RetroDan... Also I was thinking about an application similar to the ButtLoad, but instead of using the serial com, I was thinking using I2C. We'll see.

This thread is marvellous.!!! I really like it.. I have been learning alot form just this one... :wink:

---
ARod

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

I forgot to mention that I also ordered the BF carrier... seem to be a handy tool... do you think that I should order another BF, in case that fail?.. well I also ordered the STK500 so I guess would fix the lock-up problem, if it appears!

---
ARod

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

Just my personal opinion... I think for the price you'll probably wish you'd ordered two ButterFlies.

To use an old Retail Term "One to show and one to Go!"
Or if you're more a computer hacker "Always have a Backup!"

If something's not working, you can always determine
if it's a hardware problem by switching one-for-the-other.

Just a thought, for the price of a few burgers.

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

ARod,

I'm delighted to see that this thread has inspired you. My fear was that it would scare people off.

As far as extra Butterflies, I personally do all my development with at least one Known-Good-System (KGS) sitting next to my System Under Development (SUD). Then if I come to a real puzzler, I can revert to the SUD which with Butterflies this is especially good in isolating a problem to the PC or the cable or the Butterfly. If something still works on the KGS but not on the SUD then I've put a fence around the problem (usually).

The real trick is getting the KGS working first. Some folks have had a regular nightmare getting started with the Butterfly in that you have so many things that can go wrong. Is it Brays terminal set up wrong?
Is it an odd RS-232 cable?
Is it the way you've soldered the DB-9 connector to the Butterfly?
Is it the Butterfly hardware? Is it the Butterfly software?
Are you just cursed and need to get a job at McDonalds?

It seems 99% of the folks get the Butterfly going right off, and the other 1% just get driven nuts by something that turns out to be very simple (like forgetting to check the CRLF box on Brays). Of course some of those 1% start off nuts, which may explain a few of the problems I've seen.

Also the Butterfly Carrier is an excellent way to make the Butterfly more robust and easier to expand. I use it in several professional development projects.

Good Luck,
Smiley

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

I agree, to get going the first time can be a struggle unless you just happen to luck into
getting everything perfect the first time. And there a few gotcha's like me pressing, but NOT holding down the joystick button in centre position to get AVR prog to see the device.
Musta' made 1/2 dozen cables before I figured it out. But then again...

*** Of all the things I've lost.... I miss my MIND the most! ***

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

Dan, the sequence is:

1) Start ButtLoad
2) Enter STORAGE MODE instead of AVRISP MODE
3) Program in the bootloader of your choice into STORAGE MODE. The Butterfly does *not* have to be connected to the target at this time.
4) Exit STORAGE MODE, connect ButtLoad to the target. Enter PROGRAM AVR mode.
5) Select DATA ONLY from the list. You should see "PRG>D" shown on the display briefly before a sucess message.

You can use STORAGE MODE just as it was the target (including fuses, EEPROM and lockbytes), and then download them to the actual chip at a later date via PROGRAM AVR. I've never tried it with a bootloader before, so i'm interested to see if it works.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

alejmrm wrote:
Hello guys,

I just ordered my BF today from digikey, I will take some time to see if I can have the same problem as RetroDan... Also I was thinking about an application similar to the ButtLoad, but instead of using the serial com, I was thinking using I2C. We'll see.

This thread is marvellous.!!! I really like it.. I have been learning alot form just this one... :wink:

You mean I2C data in, serial data out? I could add in that to ButtLoad, but I currently have the restriction of codespace - any more code and i'll start encroaching onto the bootloader's space and thus prevent those with bootloaders from running my code. I was actually thinking about removing Direct Dataflash support from ButtLoad to free up space, since that feature will probably never be used and can be replicated via the AVRISP mode's SPI COMMAND feature and clever computer software anyway.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Here what I tried Dean.

I connected ButterFly with ButtLoad to PC via serial DB9.
I disconnected the 2nd ButterFly.
I then I downloaded various BootLoaders into the ButtLoad BF's memory.
The I disconnected the ButtLoader from the PC and connected it to 2nd
BF via ISP port.
Not knowing what I was doing, most of the time I think I selected ERASE before
I tried to reprogram problem BF, because most of the options said things like Data ONLY and EEPROM only and the problem is with the Fuses/LockBits(?)

Anyhow all I ever got was Sync-Errors. So as of right now I can't say one way or the other if it works. Seems strange that same connections will allow me to reprogram problem BF from AVR Prog but not from ButtLoad. I do intent to try again after I get feed-back from you on procedure. You say I only use the Data Only Option without Erasing
first?

Anyhow, I can say with a fair amount of certainty that the new "Official" bootload from AVR seems to be extremely well behaved. I have not had a single problem in about 60 burns so far today and the failure rate prior that was about 1/10 to 1/20 burns.

So I hope that are shipping new BFs with this new version.

TTYL

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

The storage mode, being unique to ButtLoad, seems a little temperemental. I've found that in any cases cycling the power to both the target and ButtLoad will clear up the sync error but I havn't had time to track down the problem in-depth. I'll be leaving for a two week holiday to China with my family on Tuesday, and so will be unavaliable during that time.

Yes, DATA ONLY is all you need, as it performs an erase automatically. DATA ONLY programs the target with the program data stored in ButtLoad's memory, EEPROM ONLY programs just the EEPROM stored in memory, and the LOCK and FUSE settings program in the respective stored lock and fuse settings from ButtLoad's memory.

See if the power cycling fixes the problem. If not, i'll see if I can set some time aside today to check it out on my end and see if I can see what's causing the sync errors in some cases.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

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

Okay will do!

Next time I try I will make sure both ButterFlies have been Freshly Reset and I will just use the Program Data Only Option.

Perahap, to make your program more robust, just skip the error checking and just go ahead with the "burn" anyway. I don't imagine it will harm anything will it? That might save you some valuable programming space and if it fails to burn another chip the guy is going to check his cables, etc anyway.

Just a thought.

Enjoy your trip!

PS. Still no problems with new AVR ButterFly BootLoad.

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

Dean,

What I was thinking is to design a "mini"-buttload with the capabilities similar to ButtLoad "STORAGE MODE", so the user will store the firmware into the dataflash(using AvrStudio), then the user will carry the BF to a given location, and use the "ISP MODE" to change the firmware of the failing product, but the "ISP MODE" that I will use is using the I2C protocol instead of the SPI protocol... obviously this implies that the "product" needs to have a bootloader that understand I2C...

Well, I am still brain storming this idea... thanks for the inspiration.

---
ARod

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

Hi. Don't miss the latest "ButterflyBoot v1.2.hex" enhanced Butterfly bootloader firmware release.
With power management (down to 40% of the power consumption of the Rev1.1 and the official ATMEL's firmwares) and an improved programming engine, that probably eliminates the 0x940C bug.
Get it here: http://www.avrfreaks.net/index.p...

George.

I hope for nothing; I fear nothing; I am free. (Nikos Kazantzakis)

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

Can anyone Confirm if the new ButterFlies are being shipped with the new Bootload software?

BTW - what are they going to do (if anything) about the ones sitting on suppler shelves?

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

CAN WE PLEASE LET THIS THREAD DIE AND DO ALL FURTHER POSTS ON THE 0x040c ISSUE WHERE IT CAN DO SOME GOOD?

PLEASE PUT FUTURE 0x940c ERROR POSTS ON:

http://www.avrfreaks.net/index.p...

SO I CAN CONSOLIDATE THEM INTO A SINGLE USEFUL POST.

FOR POSTS UNRELATED TO THIS ISSUE PRECISE, PLEASE START A NEW THREAD.

Smiley

Pages