The AVR ISP MKII should work just fine in AVR Studio 6.
Sure, but that's a driver issue, a pretty GUI won't fix that.
Flip back a couple pages..... he chose not to use it.
The amount of misinformation in this thread has been staggering.
No offence Dave, you spent a large part of the first 45min of the 5h live video ranting about avrdude, drivers and avrstudio.
After confirming firewalker's solution you could've marked the thread as fixed and/or edited your original post summarizing your mistake.
The AVR line has two FLASH memory spaces: The firmware memory space, which is fully accessible by the User in R/W fashion, and the calibration memory space where the calibration/signature/etc. chip data is stored. That special memory space size is one page long (varying from 8..128 words for every chip family or FLASH size) and it is accessible through special undocumented programming instructions.
Now, if the ISP data cable is long enough (or poorly constructed) a programming instruction opcode can be corrupted and randomly match the opcode of an undocumented instruction, most commonly resulting in erasing the target chip calibration data space! That happens because the ISP protocol erase_cal_space instruction opcode is only four bytes long (just as the FLASH/EEPROM chip_erase instruction also is), and different in one bit only from the chip_erase opcode! The documented FLASH/EEPROM Memories Chip_Erase opcode is '0xAC 0x80 0x00 0x00' and the undocumented erase_cal_space opcode is '0xAC 0xC0 0x00 0x00'.
I have found out some of those undocumented opcodes by using a custom, fully configurable AVR programmer I designed back in 2002, that supports all the ISP/HVPP/HVSP modes, by later adding to its firmware some intelligent opcode searching/verification algorithms.
Custom AVR Programmer
Anyway, if the calibration data space is erased, then the chip signature will be reset and read FF.FF.FF! The signature will be read as 00.01.02 if the programming protocol is parallel (HVPP) and the target chip is missing, resulting in the programmer hardware reading back the address it has just sent to the missing target chip, since the same 8-bit data port of the target chip is used for data and for address transmission as well. The same also applies to the serial ISP programming protocol.
These are the contents of the first four data words (residing at the calibration address space 0x000..0x003) of the 64 data words stored at the calibration data space of a ATMega328-PU:
Custom AVR Programmer, m328 calibration space 0x000..0x003: The cursor points at the higher nybble of the [L]ow byte of the Word at 0x[000], according to the obscure '000L' information at the beginning of the first LCD line.
The User accessible data are the signature bytes (1E.95.14) and the 8 MHz oscillator calibration byte (0x8F).
This is the complete calibration space data dump of that specific chip above, as reported by the programmer through its UART line:Code: [Select]ATnega328
0x0000: 1E.8F 95.FF 14.D1 FF.26 FF.0B FF.17 FF.FF 4A.31
0x0008: 34.30 36.34 FF.03 1E.04 17.01 12.05 13.05 FF.FF
0x0010: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF B8.87
0x0018: BC.55 53.63 AE.8F C3.46 B9.75 99.0F 57.0B D4.0E
0x0020: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF
0x0028: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF
0x0030: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF
0x0038: FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF FF.FF 75.06
These are the signature bytes read with the m328 programming socket populated in the first picture, and with the socket empty in the second one:
Custom AVR Programmer, m328 signature read
Custom AVR Programmer, empty socket signature read
The problem is Windows' lack of a unified USB API and shitty driver model, not avrdude. Let's place the blame where it belongs.
I find when you start messing with drivers and weird hacks to use your oddball stuff or do oddball things it's time to boot Linux where things just work (tm). As is the case here.
eh. that's not true. winusb is the built-in uniform USB access layer.. it's just that nobody uses it ... they all want to muck around with libusb and other 3rd party crap....
Why don't you all take your PIC's and AVR's, and their development tools, push em together in a big pile , run over em repeatedly with some heavy trucks, douse the remainders in some gasoline and set them on fire.
And then switch to a nice ARM Cortex based machine like an STM32 cpu. They have a 32 bit processor for 32 cents now ... in SO package. You can't beat that !
http://www.st.com/web/en/press/p3444
And then switch to a nice ARM Cortex based machine like an STM32 cpu. They have a 32 bit processor for 32 cents now ... in SO package. You can't beat that !
http://www.st.com/web/en/press/p3444
I've done a bit of each and as far as the free tools are concerned, AVR and MSP430 are orders of magnitude easier to get working than ARM. Just bringing a toolchain from compiled to compiling running code is a chore, requiring linker scripts, startup code, libc stubs etc. to be provided by the user while this is mostly automated in AVR and MSP430 tools.
The ARM chips are powerful, cheap, and flexible but the variety means you basically need to do all this junk manually every time you use one, and especially for someone not steeped in embedded development it's not an easy task and certainly not well documented. The manufacturers seem to expect you to just shell out for the $500-5000 tools where it's all built in.
No need to compile an ARM toolchain from source, just download one from here.
I've never touched AVR, but I've used MSP430 "professionally" and the tools provided by TI make me tear my hair out (what little there is left). The MSP430 is fine if you stay within the 64K boundary, but going beyond that limit turns it into a wicked hack. ARM with it's 32-bit design, is smooth and creamy all the way from tiny sub $1 parts up to M4 monsters. Combine that with a GCC toolchain that pretty much "just works", and it's a great architecture--well worth your time to get comfortable with.
Hey, fifteen bucks buys you a STM32F4Discovery board. It's got one of those monster M4 mcus on it (1M flash and 192K RAM!), plus an on-board programmer that you can use for any other STM32 mcu. It's gotta be one of the best deals out there. And if you're an RTOS fan, then check out ChibiOS (www.chibios.org). The guy who wrote the kernel works for ST and most of their mcus are supported out-of-the-box. It's got a really active community and the quality of the code is amazing for an open source project. Check it out!
It is a fact that AVR Studio 6 is a bloated piece of crapware. Whenever I am able to, I am still using the lightweight (in comparison) AVR Studio 4.19 (build 730) that also plays nicely with WinAVR (for any possible issues of AS 4.19 with WinAVR, please read this).
As for using poorly constructed programmers, I think that the following information might shed some light on the possible problems might arise from using "affordable" programmers:The AVR line has two FLASH memory spaces: The firmware memory space, which is fully accessible by the User in R/W fashion, and the ...
-George
I have found out some of those undocumented opcodes
With some parts was able to accidentally do it relatively easy (FF:FF:FF:FF sign). With AT90S2313 and AT90S1200. Did you noticed something similar or was something wrong with me and those chips?
And where is the link for your programmer?
I don't suppose you've seen these written up anywhere, or written about what you've found yourself?
eh. that's not true. winusb is the built-in uniform USB access layer.. it's just that nobody uses it ... they all want to muck around with libusb and other 3rd party crap....
I am using their Basic compiler for ARM.