AVRdude cannot use v4 due to no software reset. Also I am having a difficult time putting the BP into DIO mode (by sending 0's) but then again I couldnt get v3 to do it; though only tried once on v3.
Anyways I would like to propose a hidden (by hidden I mean just hidden from the menu) but it may help any application that wants to use the BP in binIO mode.
I think that we should add a procMenu command; such as '!' or if possible a string '!DIO" to enter dio mode instead of 0x00. Then perhaps we could get the AVR guys to create a BusPirate programmer (already made) and a BusPiratev4 programmer that ignores the reset and instead enters DIO by sending that 'hidden' command. And perhaps add that support to v3 as well.
It would be a super simple fix; and it shouldnt be put on the public '?' menu it should be documented but for developers to use; not so much regular users playing with there BP.
If you guys think its a good idea (I would like to see BP4 have AVRdude support) and Ian gives me the OK; I will code that in and get with the AVR guys to get it fixed.
A second way of fixing this is creating an AVRdude mode you enter; and I could program that mode to emulate BusPirate3 and get it working that way...
A single command to BBIO mode is risky. That is how we started (0x00 once), but then all sorts of terminal programs barf characters at startup and people end up in binary mode.
I swore we got a patch to avrdude that stopped resetting and parsing the header. It's caused tons of problems.
Oh alright; I will contact the AVRdude guys, I know Dean a bit (not socially; just PM back and forth on AVRfreaks) but enough get this thing fixed.
[quote author="ian"]A single command to BBIO mode is risky. That is how we started (0x00 once), but then all sorts of terminal programs barf characters at startup and people end up in binary mode.
I swore we got a patch to avrdude that stopped resetting and parsing the header. It's caused tons of problems.[/quote]
Wasn't the real problem there is no public build of avrdude that contains this patch? Or some old version ended up in some avr-gcc distro?
You're right.... we should do the bare minimum to get it working with all the crap that's out there. I swear we've been through this several times though. It means we will need to emulate the reset (and info display) of a v3 on v4.
/ian hauls out Arduino and ATTINY13A
Ok, added this to the list for today.
I vote against a v3 emulation mode just for AVRdude. We made too many consessions already for AVRdude IMHO.
The 5.11.1 source Tayken linked in the other forum has a beautiful AVRDude interface to the Bus Pirate. It still does the reset, but it parses the firmware and hardware version nicely. All we have to do is make # print RESET and the info menu and it should be ok. There are probably other binary mode problem on v4, like polling the UART directly instead of using the USB routines.
I have to finish a few things this morning, but I am going to do another day of BP debug this afternoon and three AVR things are on my list.
[quote author="Sjaak"]I vote against a v3 emulation mode just for AVRdude. We made too many consessions already for AVRdude IMHO.[/quote]
I second to this, we don't have to emulate v3, we may break something with the actual hardware. Instead we can patch up avrdude (just removing reset part will do I guess) and either publish that patch or compile for different systems and publish the binaries too. I'm up for writing a script (of course Linux) for this, got pretty busy but will have some time in my hands after tomorrow.
[quote author="ian"]The 5.11.1 source Tayken linked in the other forum has a beautiful AVRDude interface to the Bus Pirate. It still does the reset, but it parses the firmware and hardware version nicely.[/quote]
Pretty good eh? Source clarifies lots of things.
[quote author="ian"]All we have to do is make # print RESET and the info menu and it should be ok. There are probably other binary mode problem on v4, like polling the UART directly instead of using the USB routines.[/quote]
Hmm, I don't get you there. v4 acts like any serial port device, why should we care about using USB routines? Don't we provide the virtual serial port only?
[quote author="ian"]I have to finish a few things this morning, but I am going to do another day of BP debug this afternoon and three AVR things are on my list.[/quote]
OK, please tell me how it goes. I'll update the firmware I have tomorrow to the latest test version and start cracking at avrdude codes. I'm guessing that patching up buspirate.c will do the trick. We can even keep the algorithm for v3 and get hardware version and do a if..then..else for adding v4 support. This way avrdude can just reset v3 but will not reset v4. Also we may not have to check it from BP messages, v4 can be entered as an extra option just like reset pin etc. BTW we also have to add support for using extra AUX pins we have anyhow.
Didn't go great :) Had a server outage, hired someone to do a new one, other busy work. No time to play with hardware. It gets pushed to tomorrow.
The UART issue is in the binmode code. To make it faster I polled UART data ready bits directly instead of using the bus pirate abstractions. When we moved to USB we added USB equivalents of the abstractions, but they didn't fix the places that currently access the UART registers directly.
First things first. I attached the BPv3.5 to an Arduino, It does work. Downloading the flash now but is slow as molasses. Will probably get that 40x speed improvement patch installed in a second.
Next I will try with BPv4 and the latest patches. I'll check the code for hard-coded UART stuff and get as far as I can with the goal of working AVRdude in BPv4 firmware v6.
After that I will play with the EEPROM, and try to generally get a handle on v6 firmware release. That's a different thread though.
Fixed a few issues:
1. BBIO mode exit was resetting with ASM reset command, caused USB to fail, avrdude to hand
2. Added cleanup and exit from BBIO mode, show info screen to emulate v3 BBIO exit
AVR dude no longer hangs with v4. There is still an issue actually detecting the AVR. Looking into that now.
[quote author="ian"]Fixed a few issues:
1. BBIO mode exit was resetting with ASM reset command, caused USB to fail, avrdude to hand[/quote]
Ohh.. well that explains that..
In buspirate_enable function (avrdude source) there was a reset command (ascii), they are using it to get the hw and fw versions. Changed it to info command (ascii), had to play around a little to display results. I am able to get hw and fw version info. Also changed the reset in binmode (0x0F) to return to binmode (0x00). Only error I'm getting is to reset failed so I have to powercycle it. Will try comm with actual ICs in a few.
Fixed all the issues. v6 alpha 6 should work with AVRdude
[quote author="ian"]Fixed all the issues. v6 alpha 6 should work with AVRdude[/quote]
Yeah, works fine, no need for my "hacks" :)
But I'll add the reset pin functionality to AUX1 and AUX2 pins once we add the capability to binmode. Currently "0100wxyz - Configure peripherals w=power, x=pull-ups, y=AUX, z=CS" command does not have enough room for adding AUX1 and AUX2, if we make it 01wx'y0''y1''y2'z where y*=AUX* we can end up setting SPI speed and other possible mixups can happen.
we should start with the 40x speedup patch, and add a new BBIO entry command. Using 0x00 by 20 is taking mor etime than any other part of programming.
Maybe 0x00 0xff 0x00, that fits in the buffer. It could be quick jump to BBIO in one command wihtout accidents from stupid terminal apps.
That change can be done pretty easily, just change line 429 of buspirate.c from
char buf[20] = { ' ' };to
char buf[3] = { 0x00, 0xFF, 0x00 };in order to set the new init condition for avrdude.
Hi there, what is the current status? I have a BPv4 with firmware v6.1 r1676 and I tried avrdude 5.11.1 with the patch from https://zencoding-blog.googlecode.com/s ... rate.patch (https://zencoding-blog.googlecode.com/svn/trunk/buspirate/avrdude-5.11-buspirate.patch)
The first time it worked (it tried Binary Mode, failed, fell back to ASCII and succeeded in reading the identification and fuse-bits). Since then, everything failed. I added some debugging-output to AVRdude's buspirate.c (function entry) and here's what I found out:
- ASCII mode:
AVRdude doesn't set a mode. So after power-cycling the BP (HiZ-mode), the PowerOn-conmmand fails (not supported in that mode). Could be fixed in AVRdude but might break compatibility with v3/oder firmware?
Switching to DIO manually before running AVRdude makes PowerOn possible but fails later, setting SPI-mode manually gets me further but fails somehow later. Don't ask me why it worked on first try.
- Binary mode:
Initialisation and PowerOn working, gets stuck later. Output from AVRdude (verbose + function entries marked):
kripton@miramis ~/raspberry/bitwizard $ avrdude -c buspirate -p t44 -v -P /dev/ttyACM0
avrdude: Version 5.11.1, compiled on Jul 10 2012 at 18:06:32
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/kripton/.avrduderc"
User configuration file does not exist or is not a regular file, skipping
Using Port : /dev/ttyACM0
Using Programmer : buspirate
START: buspirate_open
AVR Part : ATtiny44
Chip Erase delay : 4500 us
PAGEL : P00
BS2 : P00
RESET disposition : possible i/o
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 6 4 0 no 256 4 0 4000 4500 0xff 0xff
flash 65 6 32 0 yes 4096 64 64 4500 4500 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Programmer Type : BusPirate
Description : The Bus Pirate
START: buspirate_enable
Attempting to initiate BusPirate binary mode...
START: buspirate_send_bin:
START: buspirate_start_spi_mode_bin
START: buspirate_send_bin:
START: buspirate_recv_bin:
BusPirate binmode version: 1
START: buspirate_send_bin:
START: buspirate_recv_bin:
BusPirate SPI version: 1
START: buspirate_send_bin:
START: buspirate_recv_bin:
avrdude: Paged flash write enabled.
START: buspirate_send_bin:
START: buspirate_recv_bin:
START: buspirate_send_bin:
START: buspirate_recv_bin:
START: buspirate_send_bin:
START: buspirate_recv_bin:
START: buspirate_send_bin:
START: buspirate_recv_bin:
START: buspirate_send_bin:
START: buspirate_recv_bin:
AVR Extended Commands version 0
START: buspirate_initialize
START: buspirate_powerup
START: buspirate_program_enable
START: buspirate_send_bin:
START: buspirate_recv_bin:
START: buspirate_cmd
START: buspirate_send_bin:
START: buspirate_recv_bin:
avrdude: initialization failed, rc=-2
Double check connections and try again, or use -F to override
this check.
START: buspirate_powerdown
START: buspirate_send_bin:
START: buspirate_recv_bin:
^C
Any ideas?
I'm sorry, I have not personally tested this combination and don't know if it will work on v4. There are a couple problems in v4 USB stack that could effect high-data applications like AVRDude, I need to work those out first, then many of these will stop being a problem.
I will start a bug report on the tracker.