AVRdude unable to open port for Bus Pirate

[MathWizard]

I've been playing around with an ATTiny13A, and I finally got a blink code working on it. I had to use my Arduino uno clone, as an ISP. That took longer than it should have, since I tried using the ICSP header, but what should be the reset pin, on some boards, isn't on this one.

So anyways I know some AVRdude stuff is working on my PC. But so now I'm wondering why AVRdude/dudess gives errors, when I've tried using Bus Pirate in SPI mode to talk to the ATTiny13A. I know the tiny doesn't have full SPI, but they call it that in the datasheet. And I'm connecting the BusP ChipSelect pin to the reset of the tiny.

For the Bus Pirate, it's version v3.6, v3b , firmware v5.10, bootloader v4.4. I'm pretty sure it's USB drivers and all that work fine in win10, using Putty terminal, today anyways. It's com port is set for 115,200 , 8n1n.

In the BP SPI mode, I choose default clock polarity and phase, I've tried 30kHz, 125kHz as the speed, and open drains, and I have the pull-up's enabled, and a jumper connecting the Vpullup to Vcc.

I used the Bus Pirate's UART for some STM32 stuff, and I seem to remember entering some UART-bridgemode, then exiting the terminal. Is there anything like that I'm supposed to do for SPI ?? Because the main AVRdude error I get is that it can't connect to my COM port.

I've tried to get the latest versions of these, but IDK. I've installed WinAVR, AVRdudess 2.17(AVRdude v7.3), and tried AVRdude v8.0. But in powershell it says it AVRdude v5.10 so IDK.

But anyways in AVRdudess, with the correct COM port, Brate, and ATTiny13A chosen, if I hit detect MCU, no matter what programmer I choose, like

The Bus Pirate
The Bus Pirate(bitbang.....)
Atmel STk500 v1
ft232r

I always get

avrdude error: unable to open port COM7 for programmer buspirate
A possible candidate serial port is:
  -P COM7 or -P ft232r

AVRdude in powershell says about the same thing.

 Well now that I got the ArduinoISP to work, I know the fuse bits and basic config are set, and AVRdude works (at least some copy on my PC, maybe just in the Arduino folders??) , and so does the chip. But when I try the BP over SPI mode, I still get nothing fr4om AVRdude, just trying to detect the ATtiny.

I did try a few different Baudrates, changing it in device manager and Putty. 9600 gave me problems with the terminal, not responding at all.

But now for sure the ATtiny main internal clock is set to 9.6MHz, so 115,200Br should be ok. But I read the intenal osc is not that great, and my chip could also be a fake, so I should try some other Brates.

[xvr]

avrdude error: unable to open port COM7 for programmer buspirate

From this message I can guess that avrdude just can't open COM port. No BusPirate communication even tried. May be COM7 port already opened by someone? Terminal, Arduino or whatever? COM ports always is open in exclusive mode - only one program can keep them opened at any time.

[MathWizard]

Well I'll try it again, now that I got AVRdudess to work, with the ArduinoISP. And for it, when I tried it's COM port, I got a same or similar error, but it recommended I use some  usb:2341:0043 as the port for COM3. I have to look that up, yeah USB and operating systems are way out there, way too many transistors. Then I had to set the read/write format to Intel Hex, more stuff that a hobby-programmer has to learn I guess.

For the BP, I tried using 'ft232r' as the port, I'm sure I tried using some ft232 chips as the programmer, in that list. I'll try all that again, but all that I read elsewhere, this version BP should be upto the job.

But overall what this was really about, was I have an ATmega169pa from a thermostat, that seems to think  the temp is way lower than it is, and turns on the heat.

And using the Ard.ISP, and AVRdudess, I was able to read the Fuse and lock bytes, and so it seems, dump the main program and eeprom.


But AVRdude in powershell still won't do any of this. Trying to run avrdude.exe from the AVRdude v8.0 directory, well that doesn't work any better. Neither did trying to run the copy in Arduino's user's/mer/appdata...... location.


So I'm pretty sure the ATmega169 has a problem, so I'll get a new one and try flashing it. And try some experiments on the old one.

The journey goes on, I want to see what those hex files translate to.

[MathWizard]

I'm trying to figure out what this .hex format even is, and I chose Intel Hex format, and looking at that format, this can't be that, there's no HH that can be the record type , and surely the address offset # would be way wrong for a ATTiny13A with 1024 bytes of program flash.

For an ATTiny13A w/ a blink progam on there, the 1st full line of the flash.hex, before the next 3A, is

3A 32 30 30 30 30 30 30 30 30 39 43 30 31 36 43 30 31 35 43 30 31 35 43 30 31 33 43 30 31 32 43 30 31 31 43 30 31 30 43 30 30 46 43 30 30 45 43 30 31 31 32 34 31 46 42 45 43 46 45 39 43 44 42 46 32 30 45 30 41 30 45 36 44 38 0D 0A

So if I'm doing it right, there would be h32=d50 data bytes, and the 16-bit beginning memory address offset would be h3030=d12336

And then there is no HH pair thats 00 to 05.

There's 77 hex pairs, counting the 1st 3A.

So what is this, or what am I doing wrong. All this MCU stuff and computers in general, are very annoying to look up, I just get the phonebook, or useless pages. I keep trying to look up AVR opcodes and AVR machine code, and all I get is the assembly, but barely a mention and no explanations about the the machine code. That what I expected the .hex file was going to be. So I was trying to crack that, until I learned 3A is just the damn : in intel Hex. But what IntelHex is this from AVRdude

[xvr]

Looks like Intel HEX format file been opened as binary.

[MathWizard]

The file is just flash.hex, with Intel format chosen in AVRdudess, the Hex readers/editors I've tried are HxD, and Hexinator. They look the same in both. I've tried a few settings, nothing has changed the hex values.

Ok after looking at someone else's arduino blink prog hex file, I see the actual IntelHex is also displayed in HxD. So there's some other hex encoding/decoding, before at the end putting it back into readable IntelHex. So 32 data words, and the program should actually start at address zero after reset. And now to see if that's a Relative jump command Like I've read is common for AVR. Below is the thermostat 1st line.

:2000000000000101020207070404050506060707080809090E0E0F0F0C0C0D0D0E0E0F0FD8


yeah I thought those repetitions looked at bit suspect, and looking up the lockbits, this thermostat chip has reading/reading disabled. So time to see if there's any easy way around that.