BUTTLOAD Programmer - V3.0 RELEASE

Go To Last Post
333 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello fellow freaks! After close to two months hard work during my end-of-year school holidays, i've finally gotten my ButtLoad project to the point where I think it is stable enough for a public beta. By all means try it out but i'd appreciate it if you would post your thoughts, suggestions, requests and bug reports here so I can attend to them.

Firstly, what is ButtLoad? In short, it's a replacement for an AVRISP but with more features. All you need to get it going is a AVRButterfly board, avaliable from our very own Smokey (www.smileymicros.com) or the current AVRFreaks T-Shirt offer. Once loaded, the system's ready to go - no hardware modifications, existing programmers or bootstrap cables to worry about! Since all the changes are in software, all you need to revert your butterfly back into its previous condition is just reload your old firmware.

ButtLoad is a cheap alternative to the more expensive programmers, and is faster to build. Not only that, but it offers more features than the official AVRISP - and you can always use the Butterfly as a development board afterwards!

Features:

AVRISP Emulation - works with AVRStudio

Self powered - does not need to be connected to a circuit to interface with AVRStudio

Transparent support for large flash memory AVRs (up to 256KB)

Can store a 256kb HEX file, EEPROM, fuse and lockbytes in non-volatile memory

The last one is what makes ButtLoad so special. Unlike other programmers, ButtLoad allows you to store a complete application into the onboard Dataflash for later retrieval. That means you can program your AVRs without the nessesity of a computer after the initial storage.

Again, I stress this is a BETA release. Not all the features I intend have been implemented. The next major feature will probably be the ability to program Atmel dataflash via SPI in the same way that the system programs AVRs. Because this is a BETA there may (will?) be bugs in the code - this is why I need bug reports. This also means that the code is still "rough" in some places. Those who are afraid of a 16 year-old's awful programming shield your eyes.

A semi-formatted manual is included in the \Support\ directory. This will also be revised for the release of the complete and finished program.

I've created an academy project at http://tinyurl.com/afbad . Please go there for the download.

Known Issues:

The maximum speed of the USI system in SPI mode is 115200Hz at 7.3Mhz system clock. Because of this (and compare granularity), BUTTLOAD's maximum ISP speed is 113,427KHz.

If no program is in the storage and a READ command in sent, all 0xFFs will be returned. If the data being read is larger than the loaded data, the extra bytes will also return their dataflash contents (rather than, and not nessesarily, all 0xFF).

A maximum of 10 fuse bytes and 10 lock bytes can be stored in memory at any one time (writing the same fuse overwrites the existing value). If it is attempted to write more than this maximum, the extra bytes will be ignored.

All HEX files must use continuous addresses from 0x0000. HEX file whose addresses are non-linear wil fail to store and program correctly.

IMPORTANT: Ensure that the target AVR's voltage does not exceed 3V at any point in time. Exceeding this maximum will cause permanent damage to your Butterfly. If you wish to program 5V parts, a level converter of some sort is nessesary.

For those without the AVRGCC, or those who's WinAVR component versions are not up to date, a precompiled .HEX file is included. The code is released under the GPL licence for now. You will need the latest AVRLibC to compile. Enjoy!

Finally, everyone say a BIG thankyou to our very own BPar. After I damaged my own Butterfly during development, he stepped in and loaned me his time, effort, equipment and wisdom. I couldn't have finished this without his help.

- Dean :twisted:

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

Last Edited: Mon. Jul 2, 2007 - 06:58 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

WoW!
Great project here Dean :)

I must pull my butterfly off its mounting
board and try this out.

This is a huge project for someone so new to AVRs.
I could not have pulled this off...I must not be studying
hard enough...

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

Very Nice Job!!!
This will help a lot of n00bs that have no idea were to start, and $80 is to much to spend. Can't wait until all the bugs get ironed out.....though I haven't found any yet.

I just have to say this again Very Nice Job!!!


My AVR Site

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

Thanks you two!

Like I said, long and hard hours getting this to work. I had to remove the external oscillator function due to technical reasons but the results are still very good :). I've patched my code to eliminate known issue #2, and have ideas to remove #1 and #4. I just want to know of any other requests or problems :D.

This is my little contribution back to the community, since you've all supported me so much so far in the two years that i've been interested in AVRs. It's about time I really started to write some decent programs!

- Dean :twisted:

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

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

A question to all those out there who store preset data in Atmel dataflash. What sort of format do you use? If I add the functionalty to ButtLoad to connect any Atmel dataflash to the system and program it, how would ou want to send the data? Would you rather have it as a HEX file and load that in like the "program flash" or EEPROM in AVRStudio? Or a simple serial protocol?

- Dean :twisted:

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

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

I just have to try this, Dean. How much it is Butt-fly related, will it work in a generic circuit with tx/rx going out through a level converter? I need some small bootloader to start with, but I have my own circuit.

The Dark Boxes are coming.

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

It's not a bootloader, but a replacement for an AVRISP. You can use it to program other AVRs via ISP. It's cheaper than an AVRISP and contains more features.

The code is pretty well tied to the Butterfly, but should be portable with a bit of work. If anyone wants to port this, I reccomend that you wait for the proper release first.

- Dean :twisted:

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

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

Ahh.. Sorry then! I got it all wrong, it's all in the name. Buttload, not bootyloader.

The Dark Boxes are coming.

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

I'd make a generic bootloader, but it seems there are already 9,000,000 of them out there. That's why I decided to go for somthing different. As far as I know this is the only open-source AVR programmer which can store a complete application and program it in at a later time without a computer.

- Dean :twisted:

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

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

This is fantastic. Just what I was looking for... I have plenty of butterfly's lying about and a JTAG but no ISP. Perfect for those projects without Jtag like all the Tiny devices.

I was just about to start work on a similar project.

So this a complete no solder solution?

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

Yep, apart from the wires to connect the Butterfly to the slave AVR. I've actually soldered headers to mine, and thus I can just use the two wire cabled that came with my STK500 to link it to the target board. Other than that, no, no parts need to be added or removed.

An exception to that case is for 5V target AVRs. You will need to implement some sort of level converter (a discrete transistor-based one is possible and uses only a few parts) to boost the 3V butterfly to 5V for the board and vice-versa. A solution might be to power the slave AVR's board at 3V for programming for a true no-parts solution.

A caution: I havn't checked the current required to program an AVR, so I don't know if this exceeds the Butterfly's MEGA169 pin output current ratings. So far (after MANY tests by BPar) no ill effects have been observed, but if you're worried some sort of buffer could be used.

Also remember that this is BETA and so may contain bugs. I'm just finishing up direct Dataflash programming feature now.

- Dean :twisted:

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

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

Dean,
I don't have any stars to the left, but good work. I was working on the same project, I feel like I am stealing to use it.

I converted your manual to .pdf format with the intent to attach for those w/o MS word, but I think the only way to do that is to start a new thread. I'm not sure if I should do that, and if I should, I don't know what forum to put it in. I'm going to go test BUTTLOAD now. Thanks Dean.

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

Stars don't count for squat around here, except a mouth-size-to-life ratio. You see my former is large, and the latter small :).

The manual's VERY awful at the moment, and unfinished. If someone skilled in document beutifying wants to have a go at making it less ugly than Paris Hilton, please be my guest. Once the code and thus operations are finalised i'll convert it to a PDF. For the record, I use Sun Microsystem's free StarOffice. All my software is currently freeware or open source, except Windows itself.

Steal away. Just remember that a) the code's GPL, so you can't sell it or derivatives without showing the source code and b) It's BETA code and thus already out of date.

Cheers!!
- Dean :twisted:

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

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

I've exported the manual to PDF for the benefit of those without Microsoft Word or StarOffice. Also attached is a quick diagram showing the possible programming modes of Buttload (main modes, plenty of ommitted stuff) just in case anyone is unclear as to what it does.

Note that the manual includes and diagram shows information about the direct dataflash programming mode not avaliable in BETA1. The code for that function is complete, but i'm waiting on success and bug reports before I release it so it is as functional as possible.

EDIT: Outdated manual removed to prevent future confusion.

- Dean :twisted:

Attachment(s): 

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

Last Edited: Tue. Apr 4, 2006 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

All seems well so far.

Now released is the public BETA V2. This beta includes small code tweaks, and the ability to program presumably any Atmel dataflash directly. Please note that the external dataflashes utilise a seperate enable pin on PORTF, previously dedicated to the external oscillator (now removed) in the private BETA versions.

I've created an academy project at http://tinyurl.com/afbad . Please go there for the download.

If someone has an Atmel dataflash around and wouldn't mind testing out the new functions, please do so and report here. Refer to the included manual (which is also included in PDF form now) for instructions.

Currently the dataflash is accessed through the USI interface like the slave AVR programming. If speed is an issue, this could be moved to the actual SPI port if feedback requests it.

As always, suggestions, comments, bug reports and anything else appreciated. Like in the previous version, a precompiled HEX is included.

- Dean :twisted:

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

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

Beta 3 code released in the project page. This is most definetly untested and serves as a true preview until I get a chance to fully test the new features to ensure they all work under all conditions.

New features are:
* Settings routines moved to a settings sub menu for more accessable main menu
* ISP lines are now high impedance when not in use; this way ButtLoad can remain connected without interfearing with SPI comms
* New software ISP line short detection - will show an error message if a short is detected on the ISP lines, but will not be damaged

I'm still looking for further suggestions...

- Dean :twisted:

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

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

do you have a more detailed schematic ?
about how to connect to butterfly to PC, and how to connect butterfly to a target.
I guess some sort of rs232 level converter is needed from the PC to butterfly ?
Great project by the way.

Yours: Thomas Scherrer - Denmark
OZ2CPU www.webx.dk

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

no level converter is needed between bfly and pc (included on the board) check out the butterfly users guide ( http://www.atmel.com/dyn/resourc... page 24).

I agree a nice pin out diagram would be sweet. If you read the main.c file you'll find

Quote:

CONNECTIONS:

* Because the on-board dataflash is connected to the SPI interface, the code uses
the USI system in three-wire mode to communicate with the slave AVR instead. This
means that the two systems can run at different data rates without switching, and
is also nessesary because the slave AVR does not have a /CS pin.

USI Interface
Pin 1 (SCK) - Slave AVR SCK
Pin 2 (DI) - Slave AVR MISO
Pin 3 (DO) - Slave AVR MOSI
Pin 4 (GND) - Slave AVR GND
PORTF (Note backwards orientation of port on board)
Pin 1 (PF4) - Green (active-high) lead of a Bicolour LED (optional)
Pin 5 (PF5) - Red (active-high) lead of a Bicolour LED (optional)
Pin 3 (PF6) - /RESET line of slave AVR
Pin 9 (PF6) - /CS line of slave Dataflash
Pin 10 (GND) - Status LED ground if used (optional)

* Level shifting circuitry must be employed that can translate the 3.3V Butterfly
signals to the target AVR's voltage and vice-versa AT SUFFICIENT CURRENT.

hope this helps.

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

Dean,

I can't wait to give this ago. I think I may be able to use it in an industrial setting because the ability to pre-program dataflash in particular is something I really need (to pre load a bunch of WAVs into a sound playing device).

Sadly the one thing I don't have right now is a Butterfly! Before I realised what Buttload offered I was just buying one for my own personal use from the Buttefly+T-shirt offer on the front page of Freaks but now I'm more eager than ever for it to arrive but it seems to be taking ages :(

Cliff

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

clawson wrote:

Quote:
...buying one for my own personal use from the Buttefly+T-shirt offer on the front page of Freaks but now I'm more eager than ever for it to arrive but it seems to be taking ages

It's been three week now, I'm waiting. But they did say to give it at least three weeks. Maybe next week???

You can avoid reality, for a while.  But you can't avoid the consequences of reality! - C.W. Livingston

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

Thanks for the encouragement, guys! Nice to know that my labours are appreciated. Sadly, that does not do much to ease the painful thought that school starts for me again tomorrow :(.

I'll work on a connection diagram now.

Clawson, you'll notice that the external dataflash programming method is a bit rough around the edges (and largely untested since noone I know has a dataflash with which to test it) at the moment; you connect in a special mode in AVRStudio, which then allows you to acces the connected dataflash via the EEPROM programming commands. If you have a better idea, i'd be happy to hear it.

Cheers!
- Dean :twisted:

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

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

Quote:
Sadly, that does not do much to ease the painful thought that school starts for me again tomorrow .

Lucky :D School ends in May here and starts again in August.(At my school) I still have a couple months until I get a huge vacation.


My AVR Site

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

abcminiuser wrote:
Clawson, you'll notice that the external dataflash programming method is a bit rough around the edges (and largely untested since noone I know has a dataflash with which to test it) at the moment; you connect in a special mode in AVRStudio, which then allows you to acces the connected dataflash via the EEPROM programming commands. If you have a better idea, i'd be happy to hear it.
Dean (call me "Cliff" by the way, only my wife calls me "clawson" when she's angry!! ;) ),

I'll be more than happy to help debug/fix any problems in the dataflash stuff but it's good that the fundamentals are already in place - even if they need the odd tweak. Just roll on the arrival of my Butterfly!

Cliff

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

Cliff it is then. The dataflash code should in theory work; after all, the generic routines are used for the internal dataflash. However there may be a bug in the external dataflash control logic code inside ProgDataflash.c.

Ouch! Looks like i'm not making a ButtProbe JTAG any time soon:

Quote:
Hi Dean,

As you know the JTAG protocol is available from both atmel.com and AVRfreaks.
The proprietary part of the protocol between the JTAG unit and our OCD system, will not be made public unless there is a very good reason to do so - as in a large-scale NDA-protected cooperation between Atmel on the one side, and some 3rd on the other side. There are, of course, a few JTAGICE clones out there that you can check out if you are interested.

The AVRISP mkII schematics will not be compromized.
I can check it for you, but do not expect much out of that.
We make our business also from selling these tools, you see....

Fair enough tho. I wouldn't want to steal candy from the metaphorical mouth of such a good company...

- Dean :twisted:

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

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

Uhhhh... Where did that quote come from? Is this Atmel or a vendor? Does Atmel actually make the things like the AVRISP mkII or do the get somebody else to make it and merely distribute it for that other company?

Smiley

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

That was in response to a request for more information about the JTAG protocol and AVRISP MKII schematics. I used the regular avr@atmel.com email address and that was a response from Eivind A. Sivertsen from the AVR applications group. He makes fair points tho, they have to eat. I'm sure i've upset them by making ButtLoad already :(.

- Dean :twisted:

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

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

All I need now is a way to detect the ISP plug being reversed completly via software, and then I believe I will have essentially all the new MKII features wrapped up completly in software. I could even extend the V2Protocol functions to use the new extentions so that with the addition of a cheap RS-232-USB converter it will emulate the MKII completly in software. As mentioned, ISP data line shorts can now be detected in my in-progress code - this is made easier since the VCC pin of the ISP connector isn't used (if it was i'd need a way for checking shorts from GND to VCC and the data lines to VCC, which is a LOT harder).

So far, i've got:

NORMAL ISP CONNECTOR:

MISO    0  0 Unused
SCK     0  0 MOSI
RESET   0  0 GND
REVERSED ISP CONNECTOR:

GND     0  0 RESET
MOSI    0  0 SCK
Unused  0  0 MISO

My current (hehe) idea that in the reversed connector, I no longer have a ground to the target circuit. I do however have a ground relative to the Butterfly on the MISO line. I also have a IO port connected to another one of the data lines, SCK on the target MOSI line. If the slave circuit has pullups on the ISP lines, I then have a very weak path for current to flow from the SCK configured as an input with pullups down to ground via the convulted path of through the target MOSI line's pullup, down the target MISO's pullup and to the butterfly's ground. The main problem with this is that in all likleyhood, the slave board's combined pullups will be significatly higher than the internal AVR pullups and thus I won't get a guaranteed state change.

The other problem is that I have no guarantee than the slave board *has* any pullups on the ISP lines.

Thoughts?
- Dean :twisted:

EDIT: :shock: Every time I fix a typo in the project description it gets yanked to the top of the list. I'm suprised noone has yelled at me by now.

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

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

Dean,
I wouldn't worry about your description moving to the top of the list all the time. Like the old cliche says, the cream always rises to the top.
Thanks again for the ISP, I used it all weekend programming a m48 in a project involving a string-pot and four 7seg LED displays. I just used the AVR ISP mode, but had zero glitches. At least with the BUTTLOADER, we won't talk about my bugs!

Ben

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

OT:The ATAVRISP mkII's USB interface is just a RS232<->USB chip? ex:FT232,CP2012(don't know if #'s are right)............


My AVR Site

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

LCD, I believe that's correct. In fact, I know it from what i've gleaned off other users (actual schematics are, as you can see from my Atmel email, under a heavy NDA) since the master controller is a MEGA128.

Ok, no one has any thoughts on my other reverse-cable problem. But another similar question. My short-detection only works if the short is from a data line (or the RESET) to GND. That's good, since the ButtLoad cable does not require the VTARGET pin. However, if there is a short on the target board from a data line to VCC, I want a software way of detecting it.

My current algorithm checks for GND shorts via enabling the pullups. If the line is low, it's being externally pulled low via a short on the target board. However, a short to VCC cannot use a similar method because there are no internal pulldown resistors. Has anyone got any good ideas on this? I was thinking about setting the port as an output low, and then checking the PIN register to see if the target board is shorting it high. However, that may cause damage no matter how quickly I check and a direct short will only send the pin into an undefined state.

My second thought was using the A/D converter. The A/D connector on the top-left of the Butterfly is rigged as a voltage divider. I was thinking of taking a reading, setting the pin as an output low, taking a second reading and then sending the pin back into a high-impedance state. Once in the "safe" state I would compare the reading and if they mismatched by a significant amount I would assume a short.

- Dean :twisted:

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

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

Just wanted to say "Woo hoo!".

My T-shirt and Butterfly arrived yesterday and I got to have my first "play" last night. I'd placed the order on Jan 12th and the avrfreaks webmaster confirmed it shipped on Jan 16th so it actually took 14 days to travel from Norway to the UK (in case anyone else is waiting with baited breath). When it arrived it was in an outer bag that worryingly said "original packaging damaged before arrival in the UK" but everything inside was intact and what I couldn't get over (and I guess only other people who have a Butterfly will know this) but the Butterfly and it's packaging are unbelievably small - it's all smaller than a packet of playing cards! Quite incredible. But it's great fun already!

Now as soon as I can get RS232/JTAG/ISP headers soldered on I'll be off to the races and ready for a bit of buttloading.

Cliff

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

For the love of (insert deity here) I hope ButtLoad doesn't kill your new butterfly :(. I don't think I could stand the loss of a second one!

When I got my butterfly in the previous deal (TShirt worn once a week religiously until I realised I was too damn weedy for it) I was amazed at how tiny the actual packaging was. Hard to believe they managed to fit both the TShirt and the Butterfly in it. In my experience everything looks bigger in real life, including "actual size" photographs. Perhaps i'm just odd that way.

Any thoughts on my short-detection ideas? Or am I alone here? No doubt i've missed somthing and my ideas are awful compared to somthing Smokey will think up...

- Dean :twisted:

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

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

Dean,

After soldering connectors to my Butterfly and getting the RS232 working I had a quick play with the resident app/bootloader then put Buttload into it. I must say it's very impressive - I like software that just works!

I downloaded my Mega16 program into it (datdflash) and then read it back and verified it was identical. Can't ask much more that that! I haven't made an ISP connection to my target just yet so up to now all my "playing" has just been with things that can be done "inside" the Butterfly.

Just a couple of real "noob" questions about it though:

1) how do I turn it off? unlike the original app there doesn't seem to be either a menu entry for "immediate power off" or a setting for "timed power off" ? (I'm a "naughty boy" so far still running off the 3V lithium button cell - maybe you are just going to tell me to use the on/off switch on my external battery pack once I've wired one up?)

2) What I want to do is store both a Mega16 application, some fuses, perhaps some EEPROM initialisation and a default set of Dataflash data all within the Butterfly so that the completely standalone device (once I've loaded it) can then be run through a number of steps by a line operator to program fuses, eeprom, code flash and initial dataflash into a target board. Is this going to be possible as it stands or do I need to moodify the code to add a simplistic filing system to the onboard Dataflash so it can store 4 different things and then pick them up later and program them separately into the target?

BTW I know it's be a bit OTT but a hex viewer that let you look at the contents of the dataflash would be good - that way a program or dataset could have an identifiable string near the start and one could easily browse to see what (and which version) of some program/data was currently held in the dataflash.

In fact, taking that a bit further have you heard of "what strings"? These are strings you embed in code/data that start "@(#)". So you might have "@(#)My program V1.3.5" embedded in the code then something looking at it just has to scan for @(#) and print out any zero terminated strings that follow to give a catalogue of what's stored there. A function that scanned the Dflash for such strings and was able to show the viewer any that were found would be a nice way of keeping track of what was currently being held in the device.

Cliff

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

Cliff,

1) I'm currently using a rather sophisticated method I thought up myself called "yanking the battery". Works great. Because others do not share my views on that , i'm working on adding the same functions as the original butterfly app.

2) Currently everything but your dataflash data can be stored in non-volatile memory. Fuses and lockbytes are stored along with some other settings inside the EEPROM (see EEPROMVariables.c) and Flash/EEPROM is stored in the dataflash. I programed the system so that 256kb of the dataflash is reserved for the program data, and the rest of the 4mbit for the EEPROM. That guarantees you you won't run out of space for the different data sets (at least until a 512kb AVR comes out) and simplifies programming since the boundaries are known. I would be hesitant to tack dataflash data onto the end of the internal dataflash because in all likleyhood I would run out of space. What I could do however is set up some code so that you can attach an identical dataflash (to the one you want to program) onto the Butterfly's SPI port (plus one reassigned pin for /CS) and I can add in a "copy dataflash to dataflash" function. Your thoughts greatly appreciated.

I've been trying to think of decent ways to allow you to check what's currently in the ButtLoad memory, aside from just plugging it into a computer in STORAGE MODE, and reading out the contents into a file. Perhaps your special named string scheme is a good idea. Again, thoughts appreciated.

Thanks for the feedback. I'm still flabbergasted that the thing works at all, let alone works for more than one person :roll:.

- Dean :twisted:

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

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

My current working version has a new function in the main menu to send the device into sleep mode. No automatic sleep has been implemented yet - I will need to make some changes to the TIMEOUT api to get that working correctly.

Also being worked on is your "tag" idea. You can include the following .H file in your project:

#include 
#include 

struct ButtLoadData
{
	uint8_t BUTTLOAD_MAGICSTRING[4];
	uint8_t BUTTLOAD_TAGDATA[];
};

#define BUTTLOADTAG(id, data) \
   struct ButtLoadData id PROGMEM = {{0x01,'B','L','>'}, data}

And then use lines such as "BUTTLOADTAG(Name, "BUTTLOAD PROGRAMMER");" at the top of your code. When loaded into the butterfly you will be able to scroll through all the tags embedded in the program data. Note that each tag must have a unique name (not actually saved into memory), and each tag has a maximum of 20 characters plus automatic null terminator and 4 byte tag header as set by the ButtLoad code.

Currently I have a Heisenberg-esque problem with reading the tags. Take the following two scenareos:

Quote:
A section of the program data has 0x23, 0x61, 0x01, 'B', 'L', '>', 'T', 'E', 'S', 'T', 0x00, 0x12, 0x74. When reading, the 0x01 is encounterd, and the system then reads in the following four bytes. They match the tag header and the system then reads out until it reaches the 0x00. It then displays the tag, and waits for the joystick to be pressed, whereupon it searches for the next tag. Operation works correctly.

Quote:
A section of the program data has 0x23, 0x01, 0x01, 'B', 'L', '>', 'T', 'E', 'S', 'T', 0x00, 0x12, 0x74. When reading, the 0x01 is encounterd, and the system then reads in the following four bytes. They do NOT match the tag header, as there are two 0x01s in a row, and thus the system ignores the data. Because the four bytes have also been read out the real tag header has been missed, and concequently the tag is ignored. Operation does not work correctly.

I'm working on a solution. I think I may have a rather crude fix for that instance, but it'll take a little time for me to code it. Expect a new release in the next few days.

- Dean :twisted:

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

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

abcminiuser wrote:
A section of the program data has 0x23, 0x01, 0x01, 'B', 'L', '>', 'T', 'E', 'S', 'T', 0x00, 0x12, 0x74. When reading, the 0x01 is encounterd, and the system then reads in the following four bytes. They do NOT match the tag header, as there are two 0x01s in a row, and thus the system ignores the data. Because the four bytes have also been read out the real tag header has been missed, and concequently the tag is ignored. Operation does not work correctly.

Dean,

I don't see why double 0x01 would cause a problem? If you are looking for 0x01,BL> then surely you start by scanning until you hit a 0x01 (no point wasting time trying to match BL> until this is found). Next you see if *(p+1) is 'B'. If it isn't you continue scanning for 0x01. If *(p+1)=='B' then you check *(p+2)=='L' and so on, otherwise revert to scanning for 0x01 again.

How would that be upset by adjacent 0x01's ?

By the way, @(#) really IS a better prefix than a made up one like 0x01BL> because there are many software development tools that already do the @(#) scan thing anyway. I attach my DOS based what.exe that I use that just scans binary files for @(#) strings and prints them.

On the subject of Butterfly Dataflash what I was thinking (as I drove home last night) was that in the 4MBit flash on the Butterfly you could reserve 256KB for code flash (cos we agree that, at present, that's the largest AVR program size) and then the other 256KB for dataflash (minus the last page or two for the fuses/locks/eeprom). Maybe this is selfish but I think that 256KB would be sufficient for my own pre-load requirement. I may have a look at making this modification for myself anyway which would raise the question of whether you have any plans to make an open CVS for the source so that more than one person can contribute mods to it? Or do you just want any patched/new source sent to you and you'll consider the mods and hand merge it youself (in that case I highly recommend Araxis Merge!!)

Cliff

Attachment(s): 

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

Clawson,

I've finished the tag code as well as your requested sleep function. However, my implementation is less efficient than I want (and untested since my Butterfly is FOOBAR and i'm awaiting Zoom's package) and so I won't release until I change it to a different method i've thought of (basically your idea but using flags). I also just changed the header string to your suggested "@(#)".

Incorporating patches from other people is something I havn't thought of, since I never thought it would be sufficiently popular. However, I like to maintain a firm grip on the code as I can then know the code inside and out. Plus, my ego of "look what I wrote" prevents me from doing so :D. However, I will accept ideas and patches from others on the provisor that I reserve the right to not implement, or modify before implementing them (of course you would still get the credit for it). The GPL licence means that if you disagree with me, just download the code and change it yourself and feel free to distribute it to the world.

I could probably alter the code so that the dataflash could be used for dataflash data instead of EEPROM, or somthing similar to your idea. However, I would lose the guaranteed-to-hold-everything-you-throw-at-it-that-is-legal-for-AVRs aspect of the system which is why I was thinking of a seperate dataflash piggybacking on the exising SPI in parallel specifically for the dataflash.

I'll go fix the tag system, and then work out what I want to do with the dataflash.

- Dean :twisted:

PS: Sorry if above comes of as egotistical. I'm doing 90,000 things at once and havn't stopped to express myself correctly.

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

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

Well that was pretty darn easy! You're a genious Cliff, I was looking at it the wrong way. Anyway, the new tag reading code:

void TM_ShowTags(void)
{
	DF_ContinuousReadEnable(0, 0);
	TagExists = FALSE;
	DFPos = 0;
	
	TM_FindNextTag();

	while (1)
	{
		if (JoyStatus)                         // Joystick is in the non-center position
		{
			if (JoyStatus & JOY_DOWN)          // Next tag
				TM_FindNextTag();
			else if (JoyStatus & JOY_LEFT)
				break;
			else
				JoyStatus = 0;                 // Invalid value, clear the variable
		
			MAIN_WaitForJoyRelease();
		}
	}
	
	DF_ENABLEDATAFLASH(FALSE);
}

void TM_FindNextTag(void)
{
	uint8_t  Buffer[20];
	uint8_t  HeadBuff[5]      = BT_TAGHEADER;
	uint32_t ProgDataSize     = PM_GetStoredDataSize(TYPE_FLASH);
	uint8_t  TotalOkHeadBytes = 0;
	uint8_t  TagByte;
	
	LCD_puts_f(WaitText, NOSCROLL);
	MAIN_SETSTATUSLED(ORANGE);                 // Orange = busy

	while (DFPos < ProgDataSize)
	{		
		if (SPI_SPITransmit(0x00) == HeadBuff[TotalOkHeadBytes])
		{
			uint8_t HB;
			
			TotalOkHeadBytes++;
			
			if (TotalOkHeadBytes == 4)
			{
				for (HB = 0; HB < 20; HB++)
				{
					TagByte = SPI_SPITransmit(0x00);
					Buffer[HB] = TagByte;
					
					if (TagByte == 0x00)
					   break;
				}

				TagExists = TRUE;

				DFPos += (HB + 1);

				LCD_puts(Buffer, SCROLL);
				MAIN_SETSTATUSLED(GREEN);      // Green = ready
				return;			
			}
		}
		else
		{
			TotalOkHeadBytes = 0;
		}

		DFPos++;
	}
	
	DF_ContinuousReadEnable(0, 0);
	
	if (TagExists == FALSE)
	{
		MAIN_ShowError(PSTR("NO TAGS"));
		MAIN_SETSTATUSLED(GREEN);                               // Green = ready
	}
	else
	{
		TM_FindNextTag();
	}
}

Look OK to you? If you wouldn't mind testing the new release privately before unleashing it on the unwashed masses (:D) so I can iron out any bugs, please PM me.

Bed time for me. Getting back into the rythm of school after such a long break is awful :).

- Dean :twisted:

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

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

Dean,

Do I detect a bit of recursion in there? (TM_FindNextTag() calls itself)

With 31 bytes of data on the stack for each invocation (and the return address) then I'm not sure I'd use recursion on a limited RAM AVR myself.

Clfif

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

Yes, it's recursive, however it's guaranteed to only call itself once. Once a tag is found the function exits; If you are looking at the last tag in the program, the function calls itself to find the first tag. Because the function exits and returns the control back to the master TM_ShowTags function after a tag is found, the function will only call itself once, and even then only if it's the last tag in the stored data. For safety if no tags were found on the first search, the TagExists flag prevents an infinite loop by erroring out and returning to the main menu.

I plan on removing the DFPos variable and just decrementing ProgDataSize to save time and flash.

Am I making sense here? I promise tomorrow night after I've had some sleep i'll explain everything properly. Right now my bed is the only thing I can think of :roll:.

- Dean :twisted:

PS: If that code is even remotley bberie-esque, tell me now so I can trash it and rethink.

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

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

Ok, much more refreshed now. I tweaked the tag routines and I believe they work correctly, but of course will require further testing. To prompt my memory in the future (as well as help others), that recursion line is now prepended by:

/* The following line _is_ recursion, but the function will only ever call itself a maximum of one time. The function will call itself upon skipping from the last tag stored in the program data to the first; to guard against infinite recursion if no tags are present, the system will error out if the TagExists flag is empty after a full data read. Once a tag has been read and displayed onto the LCD, the function returns to the main tag handling routine. */

I'm almost ready for the next release. I'm having trouble getting the line:

ltoa(PM_GetStoredDataSize(TYPE_FLASH), &Buffer[6], 10);

working, as the Butterfly crashes spectacularly when it's executed. In theory, it should convert the size of the flash data (as computed by PM_GetStoredDataSize, which returns a uint32_t) into a string by radix 10 (decimal) and throw it into the 6th byte of the buffer onwards. I need to figure out what the trouble is and get that working, and then i'll be ready for someone to BETA test the new features. This release will be version 1.0.

- Dean :twisted:

PS: Thanks for the nice review on the ButtLoad project page, whoever submitted it.

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

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

Changing the lines to use the unsigned long-to-ascii functions stops the butterfly from crashing, but now it just freezes. However, writing to my butterfly now produces 0x94C0 verification errors amognst a myriad of other problems mainly due to my first ill-fated experiment. I'm sick of trying to deduce whether a problem is due to my code or my damaged butterfly; while I wait for my Butterflys which are en-route (thanks guys!) has anyone got a spare moment to test the new code out? I think i've bothered BPar quite enough for the time being...

Looks like i've claimed my first AVR victim. Well, that's 1 to me, 9000 to Smokey :D.

- Dean :twisted:

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

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

Hi Dean,

While looking through your code I have spotted this typo.

In dataflash.h line 28

#define DF_ENABLEDATAFLASH(tf)   if (tf) { PORTF &= ~(1 << 9); PORTB &= ~(1 << 0); } else { PORTF |= (1 << 9); PORTB |= (1 << 0); }

(1 << 9) should I think be (1 << 6). Just checked, and the relevant pin is pin 9 - external dataflash cs.

It occured to me it might be better to move the pins currently on PORTF to PORTB as it frees up the jtag port which you may find very useful for debugging.

Send me your new code and I will see if I can see what the problem is.

Keep up the good work,

Jim

Your message here - reasonable rates.

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

PortB is used for SPI of the DataFlash and the joystick. I asked Dean the same question and his ButtLoad code disables/enables the JTAG interface through software, though I'm still not sure you can use JTAG even then.


My AVR Site

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

Jim,

Almost correct. The dataflash /CS *is* pin nine, but that's PortF.7. PortF.6 is the slave AVR reset line. Nice catch tho - that would have caused some interesting problems.

Despite me harassing him several times a day, BPar (Barry) has offered to debug the code again. He's found more of my boneheaded mistakes, and the result is code that should be ready for release in no time. I have one more bug (non 0xFF bytes returned for data past Prog_DataSize and Prog_DataEEPROM size) and then I think it's read to be thrown out to the world.

Using PORTB is not possible. Apart from the above comments from LCD who did ask a while back, all the other port pins are tied to alternate functions - mostly the LCD. I can't use the other pins without impacting on the LCD functionalty or wasting current due to resistor voltage dividers, etc. As LCD also states, JTAG is tempoarily disabled upon program startup via software commands. Having said that, it's still possible to debug via a JTAG by removing those commands; you just won't see any changes to the Ex. /CS, Ext. /RESET or status LED lines.

Expect a new release soon. Jim, if you still want to see the new code before the release (just to play around with it, or try to find my other boo-boos if you're up to it), just ask.

- Dean :twisted:

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

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

Dean,

I see now, there is an error in the docs. Both pin 3 & 9 are shown as PF6.

I completely missed the fact that PORTB was connected to the joystick. My only excuse was that it was late on a particularly hot and sticky Brisbane night.

Is that the latest version on the link you gave me earlier? The latest files are at 10:12 this morning. I have a few hours to spare this evening, so testing / bug swatting seems in order.

Regards

Jim

Your message here - reasonable rates.

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

Jim, i've just uploaded the latest code to the pacific.net location. There are currently three major bugs which are preventing me from releasing it:

1) Large device support doesn't work. I've added the code but Barry's just tested it and all you get in a 256kb part is two copies of the first 128kb.
2) Reset line is not working in some cases. Now the lines are high impeedance i'm 99% sure i've just forgotten to set the pin as an output; in fact, I already have a fix in mind for that which I will code this evening after school.
3) There is a bug in my latest ISP short detection algorithm; the system always returns ISP short. No doubt i've done somthing stupid and misplaced a "~" or somthing.

I think I can fix 2 and perhaps 3 tonight, 1 will take a lot more effort since I have no idea what could be causing the problem with the new micro. Rest assured that i'll get it done. Also everyone give another three cheers for BPar; he found a good deal many of stupid errors in my code which would, or do, cause problems.

- Dean :twisted:

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

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

@Dean,

Didn't you understand my last PM.

The ATmega2561 is being programmed correctly with ButtLoad. Well at least with that stupid test .HEX file. It just can't be read or verified by ButtLoad. The ATmega2561 verified correctly when connected to my STK-500.

It don't think the AVRISP tool is sending the CMD_LOAD_ADDRESS when accessing consectutive addresses even though they might cross a 64 kB boundary.

Remember my test .HEX file had non-consecutive addresses (holes) in it so the AVRISP tool sent the CMD_LOAD_ADDRESS command while programming. But when reading or verifying, the tool just reads the whole FLASH.

I didn't try storage mode since my .HEX file had holes in it.

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

Ahh, ok, I see. I really need to fix that non-consecutive address problem before releasing it too.

I just recieved my honking great big package from Zoom containing the ICE, so now I can (if I ever figure out how to use it!) get a better look into what ButtLoad is doing at any given moment. Huzzah!

- Dean :twisted:

EDIT: Just remembered. I got your message this morning, Barry, but didn't get time to read it before I had to leave :oops:. Your last post makes perfect sense now :roll:

EDIT2: Jim's figured out my mistake in the short detection algorithm. Another example of me "fixing" my "mistakes" in the code at a later date.

EDIT 3: I fixed the reset line bug. Now the only problem is the verify-on-large-flash fail, and i'd like to eliminate the non-consecutive known issue before release.

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

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

Code is almost complete; verify now works on large flash microcontrollers, many bugs have been fixed, new features added and a few other odds-and-ends.

I'm still pondering the ISP short detection. I cannot detect shorts to VCC currently, as my algorithm replies on the internal pullups. Despite ButtLoad not using the VTARGET pin of the ISP connector, the user may still have a short on the target board.

How long can the pins withstand a short to VCC if they are set as output low at 3V? The Butterfly has an onboard voltage sensing input, with convenient voltage dividing resistors. I'm thinking about using the ADC to take an initial level reading, setting the lines as output-low in sequence, reading the new level via the ADC. A large difference in the two readings would suggest a short.

That will probably work, however despite the short only existing for the time it takes to take a single ADC reading, I can't see this as being a good option. My aim is to not damange the ButtLoad Butterfly in any way despite what odd-ball circuit the user attaches it to. Can anyone comment on this?

- Dean :twisted:

PS: Expect the new release this weekend, or early next week. All users should upgrade immediatly upon release.

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

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

If I added the ability to translate I2C data into serial, would anyone use it? You could make a computer program which uses ButtLoad to program external I2C memory chips. Unlike Atmel dataflash all the I2C memory chips out there (IIRC) have no standard on the commands needed to program and read them, thus native programming abilities could not be programmed directly into ButtLoad.

I'm off to go buy more pin headders. Testing and JTAGing ahoy!

- Dean :twisted:

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

Pages