Program AVRs, EEPROMs w/ AVRDude and BP

[ian]

Michal Ludvig submitted a patch that gives AVRDude support for programing AVRs and EEPROMs using the Bus Pirate as the programmer. It parses the terminal output at the moment, but I'm working on a raw SPI mode for better speed and performance.

http://www.nongnu.org/avrdude/

http://code.google.com/p/the-bus-pirate/source/browse/trunk/documents/AVRDude-buspirate.patch

New Bus Pirate raw SPI mode:
//0 resets
//send 1 for RAW SPI mode

Half-duplex SPI mode like 4bit LCD interface:
rawSPI mode:
00000000//reset
0001xxxx//low 4 bits of byte + send/read byte (reply: spi byte)
0010xxxx//high 4 bits of byte (reply: 1=ok)
0011000x//set CS pin high (1) or low(0) (reply:1=ok)
0100wxyz//configure peripherals w=power, x=pullups, y=AUX, z=CS (reply: 1=ok)
11110000//rawSPI version code (reply: SPI1)

Tips:
A byte is sent/read on SPI each time the low bits are sent (0001xxxx).
Send the upper bits first.
If the upper 4 bits are the same as the previous byte, just send the lower
bits again for a 100% increase in speed.

 You have to use a bitwise operator to move the 4bit chunks into each byte. Usually something like sendvalue=(0x20 | (value>>4)) for the upper bits, and sendvalue=(0x10|((value>>4)<<4)) to get the lower bits  (could be better). Send 0x30 to turn CS off, and 0x31 to turn it on. Send  0b01001000 ( 0x48) to turn on the power supplies (and everything else off).

[ian]

The raw spiIO mode is incorporated into the latest nightly build for v1, v2go, and v3:
http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware

To activate it:
Send 0x00 to the command prompt, Bus Pirate replies BBIO1
send 0x01 to setup the SPI mode, BP replies SPI1

Here's some minor changes and updates:
rawSPI mode:
00000000//reset, rawIO mode init (reply:BBIO1)
00000001//rawSPI mode init (reply:SPI1)
0001xxxx//low 4 bits of byte + send/read byte (reply: spi read byte)
0010xxxx//high 4 bits of byte (reply: 1=ok)
0011000x//set CS pin high (1) or low(0) (reply:1=ok)
0100wxyz//configure peripherals w=power, x=pullups, y=AUX, z=CS (reply: 1=ok)

Helpful HEX values:
0x30 (00110000) CS high (actually 0volts, CS enable)
0x31 (00110001) CS low (actually 3.3volts, CS disable)
0x48 (01001000) turn on power supply (other peripherals off)
0x40 (01000000) turn off power supply (other peripherals also off)

To write the value 11110000 (0xF0):
//first setup the BBIO mode and enter SPI mode
0x00 //enter raw mode, BP returns "BBIO1"
0x01 //setup raw SPI, BP returns "SPI1"

//now send values
0x2a //(00101111) send high 4 bits, BP returns 1
0x1a //(00010000) send low 4 bits, write value, BP returns SPI read
//send additional commands as needed

[mludvig]

Hi Ian,

I think you're making it needlessly complex and slow by sending each SPI byte in halves:

0001xxxx//low 4 bits of byte + send/read byte (reply: spi byte)
0010xxxx//high 4 bits of byte (reply: 1=ok)

What if, instead, we have a command:

cmd=0b0001xxxx  // start SPI transfer

where cmd&0x0F = "number of bytes - 1",  i.e. 0x10 - send 1 byte, 0x1F - send 16 bytes. It doesn't make sense to send 0 bytes and it's likely that people will need to send 16 bytes more often than 15, therefore:
nr_bytes = cmd&0x0F + 1
That'll be followed by {nr_bytes} of binary data, reply shall be {nr_bytes} of spi bytes read in response.

For 1 SPI byte the overhead is the same as in your "split-bytes" protocol (ie 50%, 2 serial bytes for 1 SPI byte), for 16 bytes the overhead goes down to some 6% only instead of steady 50% in your protocol. That will make a real difference on the AVR programming speed.

Sounds reasonable?

[ian]

0b0101xxxx - start an SPI transfer of XXXX+1 bytes. BP replies 1=OK and then sends a byte for each byte received.

Ok, I've added this as an option. I had been avoiding multi-byte packets so that the host and Bus Pirate were never out of sync, but it's no problem to have it as an option. You can always send 16+1 x '0x00' to be sure you're out of SPI mode and completely reset.

What hardware are you using? I'll be sure to make a nightly compile for it. I've uploaded updated compiles for v1, v2go, and v3.

[mludvig]

BP replies 1=OK
.. 1 as in 0x01? or 0x31 ie ascii '1'?

Will there be a command (commands) for configuring SPI clock/phase, speed and output mode (HiZ/3.3V)?

I use hw v1a from Fundamental Logic but never tried to flash a new firmware to it. Will give it a try.

[ian]

Yes, the error codes are 0x00 fail, and 0x01 success. I thought it would be easy to work with "if(uartinvalue){}", etc.

There can be command for those features. I set it to: CKP idle low, CKE active to idle, SMP sample middle, 250khz, 3.3volts, what would you like the default to be?

I'll add these options now:
0b0110wxyz //w=HiZ(0)/3.3v(1), x=CKP idle (low=0), y=CKE clock edge (active to idle=1), z=SMP sample (middle=0)
0b0111xxxx // SPI speed, 0000=30khz, 0001=125khz, 0010=250khz, 0011=1000khz

v1a should flash fine with the latest firmware. Let me know how it goes.

[ian]

I implemented the above commands, they're in the 2.3 preview release I just posted:

http://code.google.com/p/the-bus-pirate/downloads/detail?name=BusPirate.firmware.v2.3.preview.zip

I'll post a complete guide in the next few days.

[ian]

I posted a complete guide to the protocol:
http://dangerousprototypes.com/2009/10/08/bus-pirate-raw-spi-mode/

[pppd]

AVRDude no longer works in RAW mode after updating firmware to 3.5 as the version string sent by BP lacks the 'v' before 3.5.

I've created a patch for the avrdude/buspirate.c file which you can apply and get the RAW mode back. I have also added variable initialization for fw_v1, fw_v2 as otherwise the FW version was random.

[ian]

I'm sorry, that's my fault. I was trying to be cute with the 3v3 nightly, but forgot to replace the v before the 3.5 in the latest release. I've fixed it and v3.6 nightly is available in svn.

[pppd]

Thanks, there still seems to be an issue though. Now it fails to turn on/off the power supply with 'W' command as it says 'No mode set, M for mode'. Has this changed since the time avrdude support was created? I can fix it myself modifying the avrdude/buspirate.c but maybe there's something I am missing? Below is an extract from avrdude communication with BP:

Code: [Select]

Detecting BusPirate...
avrdude: buspirate_readline(): #
avrdude: buspirate_readline(): RESET
avrdude: buspirate_readline():
** 
avrdude: buspirate_readline(): Bus Pirate v3
**  Bus Pirate v3
avrdude: buspirate_readline(): Firmware v3.6
**  Firmware v3.6
avrdude: buspirate_readline(): DEVID:0x0447 REVID:0x3003 (A3)
**  DEVID:0x0447 REVID:0x3003 (A3)
avrdude: buspirate_readline(): http://dangerousprototypes.com
**  http://dangerousprototypes.com
avrdude: buspirate_readline(): HiZ>
**
avrdude: buspirate_send(): W
avrdude: buspirate_readline(): W
avrdude: buspirate_readline(): No mode set, M for mode
avrdude: buspirate_readline(): HiZ>
avrdude: warning: did not get a response to PowerUp command.

[ian]

I thought the current AVRDude bus pirate support was based on the binary interface mode, not the user mode. The Bus Pirate never allows power in HiZ (safe mode), so that is the correct response, it has never changed.

[ian]

Are you working just from the patch here, or the current AVRDude SVN?

[pppd]

I'm using the latest SVN version 906 ( just updated by Michal ).

I forced ascii mode with -x ascii as this gives me some info why the initialization fails and I am not familiar with the RAW protocol yet. The RAW mode fails too, but it might easily be my fault. I will look through the source code and I'll check if it fails before communication with AVR starts or later.

[pppd]

I have checked it with a few different AVRs and it seems to be working when the target CPU frequency is 1MHz or above.

I can't get it to work with my ATtiny13 powered Holiday Christmas Card which I set to use the internal 125kHz oscillator. I added the -x spifreq=0 parameter to lower the SPI frequency to 30kHz but it's still too fast as it can't connect or when it does it reads incorrect/incomplete chip signature.

It's not a big deal now as I have a separate programmer, but maybe it's something that can be fixed. Is there a way to lower the SPI clock even more below 30kHz? It does work with my avr-doper programmer when setting the low-frequency jumper.