Setup for programming a stand alone

Chris, the Shrimp has a bootloader.

Thats true but it doesn't obviate the fact that the chip is programmable by a chimp all be it one that is seemingly much more clever than poor old me.

The chip is programmable by a chimp either way. In the latter case (without bootloader) it just requires an ICSP to do it. How much kit you have is no measure of your "chimpness" :)

I have just burnt a bootloader onto a chip, then connected to the CH340, and off it went! No worries at all.

Once the ship is on a board, not one will know it has a bootloader, honest! :)

Also, Nick Gammon does have, as Crossroads showed, a way of burning the sketch as hex with no bootloader if you really want to.

I've struggled to understand why you object to using a bootloader, but I think the clue is here:

ChrisPSR: Why is everybody hell bent on using a boot loader when the sensible course for a finished product is to make the chip as independent as say a Microchip PIC. I want to get away from it being boot loaded. A stand alone chip is exactly that and not one leaning on something else in order to operate.

The bootloader is for programming the chip. Once programmed, you can unplug the programmer, add a battery or two and enjoy a truly stand-alone system (just like a PIC, but better). If all goes well the programmer will never be needed again. Each time your circuit is powered up, the bootloader will check to see if you're trying to re-program the chip, and if not will just run your firmware.

And looky here - Arduino has just come out with an inexpensive ISP for those not wanting a bootloader. http://store.arduino.cc/product/A000092

You are likely at fault with JTAGICE - probably miswired the adapter to get down to the 6-pin ICSP connector

http://www.atmel.com/tools/avrjtagicemkii.aspx?tab=devices

http://www.atmel.com/Images/doc2562.pdf See Table 1

And look at the cost of a new one! http://www.newark.com/atmel/atjtagice2/in-system-debugger-programmer/dp/68T2494 $436!

That's where the bootloader comes into play. No hobbyist is going to pony up for one of those.

Bring back the simpler AVR ISP MKii for $35.

Gone, gone, gone, replaced by the Arduino tool http://www.mouser.com/ProductDetail/Arduino/A000092/?qs=sGAEpiMZZMurtJ7VwBTl0QQvN7cFPlecA5N3J2AhfwNa2vLEy0kcGA%3d%3d

Upload Using Programmer to program into memory directly via the ICSP (SPI) pins. No bootloader is installed, your sketch starts immediately after a reset. Burning a bootloader first sets the fuses for 16 MHz crystal clock operation. Upload Using Programmer next to put your sketch on & wipeout the bootloader.

This says it all.

If you want to use a USB to serial converter then you need a bootloader on the chip. If you want to erase the bootloader use the ICSP pins. This allows you to use all the controllers memory for your sketch.

Make your own standalone ICSP programer out of a 328 chip. About 6-7 dollars. I believe Adafruit sells a kit too.

ChrisPSR: Why is everybody hell bent on using a boot loader when the sensible course for a finished product is to make the chip as independent as say a Microchip PIC. I want to get away from it being boot loaded.

This depends greatly on to what extent you figure the product will never require upgrading. If your device already has the USB functionality and a bootloader, you can deploy upgrades as executables (SFX packages with avrdude); otherwise you have to supply extra hardware to enable upgrades.

Recall set-top boxes with that serial port on the back? Little use was made of it, but that was the reason. Upgrades are - of course - needed either to add new functionality, or perhaps more likely, to correct that awful bug you only realised after selling hundreds of units.

ChrisPSR: Surely everybody must be of the mind that a stand alone is just that and not one dependent on any other piece of electronics and that's where I have found the ProMini to get as near as I can to a truly well produced end product.

And in fact, it makes a lot of sense to simply mount a Pro Mini on a "mother" board, particularly if you are not using TQFP and such-like packages.

LarryD: Make your own standalone ICSP programmer out of a 328 chip. About 6-7 dollars. I believe Adafruit sells a kit too.

But a bit hard to beat one ready-made from China at half the price.

But a bit hard to beat one ready-made from China at half the price.

I made my dedicated ICSP programer for $7 including the ZIF (for 328 DIPs) and the PCB (1 1/2 hours). Also has a 40 pin socket for 1284s. I didn't have to wait 9+ weeks.

LarryD: I made my dedicated ICSP programer for $7 including the ZIF (for 328 DIPs) and the PCB (1 1/2 hours). Also has a 40 pin socket for 1284s. I didn't have to wait 9+ weeks.

Have you published that? I am just about to do the same thing :)

CrossRoads: If you don't want a bootloader, then use an AVR ISP like this http://www.atmel.com/tools/avrispmkii.aspx

http://www.gammon.com.au/forum/?id=11638

Dear CrossRoads,

I've checked out your link and broadly this is the AVRATJTAGICE mkii that I have. However there is a visual exception and this is:

The red LED., mentioned in Atmels information, close to the output of the 10 pole ribbon cable is not singular on my device but consists of 3 Red LED's that are and remain always (to the best of my knowledge) as a pair that are illuminated and a further one unlit and this is the RH., LED., the furthest that is from the output ribbon cable. The shape and general context of the device is very similar. The manufacturing date is given as 20061206.

Hope this may help in your dissertations.

Chris

ChilliTronix:
Have you published that? I am just about to do the same thing :slight_smile:

Dear Chilli,

I post this on the forum some time ago viz.,

Broadly it consists of a Ziff feeding back to standard Arduino ports. It has been updated to include the Arduino Prototype Shield’s ICSP., pins/poles all as per the entrained pcb., circuit, (which, not curiously, happen to be exactly as the standard Arduino pin connections, which have been hard wired).

One error: I have stupidly numbered the IC’s poles mirror image. So for the Pin numbered 28 read pin1. For the pin numbered 1 read as Pin 28, add-sequence. Pin numbers provided as 10,11 & 12 should read Arduino 11, 12 & 13.

Cheers,
ChrisPSR

Many thanks, I was asking Larry, but yours is I presume similar.

I am quite likely to use a redundant Nano as the programmer soldered to strip board, and I will place ZIF sockets for both 28 and 40 pin devices. (SO I can do the 328 and 1284).

I may further modify Nick Gammon's code to run and LCD and take input from buttons.

ChilliTronix: Many thanks, I was asking Larry, but yours is I presume similar.

I am quite likely to use a redundant Nano as the programmer soldered to strip board, and I will place ZIF sockets for both 28 and 40 pin devices. (SO I can do the 328 and 1284).

I may further modify Nick Gammon's code to run and LCD and take input from buttons.

Kitchen sink and all eh'.

Well, I have some test 20X4 LCDs that I can't sell, and some other bits I also can't sell, so why not make a programmer that will allow me to sell an equivalent to the Shrimp kit in both 328 and 1284 format?

I figured out how to program the MCU in SPI mode woth chip select on the MCU eset line last night.

HOW TO PROGRAM THE ATMEGA328(p) MANUALLY THROUGH SPI

Programming the ATmega328(p) manually can easily be achieved using a standard SPI connection. By connecting the ATmega to a host MCU through SPI, programming the target can be very easy.

  1. ChipSelect - Enables programming mode on the target ATmega328(p)
  2. Issue corresponding commands from host to the target.
  3. Release ChipSelect ___________________________________________________________________________________

CONNECTIONS

HOST - TARGET SS/CS RESET MOSI MOSI MISO MISO SCK SCK V+ V+ GND GND

No external crystal connection is needed. Programming speed is determined by SPI SCK.


ATMEGA328(p) ISP COMMANDS

0xAC EXECUTABLE COMMAND PREFIX 0x20 READ LOW BYTE FROM FLASH 0x28 READ HIGH BYTE FROM FLASH 0x30 READ DEVICE ID INFORMATION 0x40 WRITE LOW BYTE TO FLASH BUFFER 0x48 WRITE HIGH BYTE TO FLASH BUFFER 0x4C TRANSFER BYTES FROM BUFFER TO FLASH AT ADDRESS LOADED INTO 0x40 AND 0x48 0xC0 WRITE BYTE TO EEPROM 0xA0 READ BYTE FROM EEPROM


OPCODE USAGE

STEP 1: Issuing the "Programming Enable" command to the target:

This is the only command the target will acknowledge initially when RESET goes low. You can enter Programming Mode by sending AC 53 00 00 to the target.

STEP 2: Reading the Device ID from the target after initialization:

The next step is to see if init occured correctly, so we have to read the Device ID from the target. Device ID can be read by issuing 30 00 00 to the target, and then read one byte back from the target checking for data first then issuing clock in that order on the bit level.

The Device ID byte should read back as 1E signifying Atmel as the manufacturer. If the Device ID byte reads as 0x1E, the device is set to be reprogrammed. If the Device ID byte reads as 0xFF, the device did not initialize properly.

If the Device ID byte reads as 0x00, then the Lock Bits are set and the device has to be erased first before you can properly read the Device ID.

Send three bytes, then read one byte for a total of four bytes in the sequence.

** Note that each command in Programming Mode is ALWAYS 4 bytes long ** ** You can also read flash size using 30 00 01 + read one byte ** ** You can also read device family using 30 00 02 + read one byte **

STEP 3: Issuing the Chip Erase Command to Erase the entire contents of Flash and EEPROM:

Before programming can occur, the Flash and EEPROM must be erased at the same time. This resets all bytes in the physical address space to 0xFF so they can be reprogrammed. Erasing Flash and EEPROM can be accomplished by issuing AC 80 00 00 to the target. ALL bytes in Flash and EEPROM become 0xFF.

** ATmega328(p) is only capable of setting individual bits to 0's from 1's during programming ** ** The unit can not program bits from 0's to 1's, so the bytes default to 0xFF after format **

STEP 4: Checking to see if the device was formatted properly:

Checking Flash to see if it was formatted properly can be done by issuing the Read Byte From Flash command. Each address location holds 2 bytes, a High byte and a Low byte.

aa=SEGMENT or MSB highbyte of address bb=OFFSET or LSB low byte of address

Example: If the Segment=00 and the Offset=01 then the ADDRESS= 0x0001

To read a low byte from an address in Flash, issue: 20 aa bb then read one byte, or issue: 20 SEGMENT OFFSET then read one byte.

To read a high byte from an address in Flash, issue: 28 aa bb then read one byte or issue: 28 SEGMENT OFFSET then read one byte.

Send three bytes, then read one byte for a total of four bytes in the sequence.

If the bytes read are 0xFF, then the device has been formated properly. The Flash address range is 0x0000 - 0x03FFF or 0-16383 for a total of 16384 memory locations. ** Each address in Flash contains 2 bytes, a Low byte and a High byte **

STEP 5: Writing a byte to Flash after proper Format:

Writing bytes to flash occurs by sending a byte to a high or low location per address in flash.

Writing a low byte to a Flash address is accomplished by issuing 40 SEGMENT OFFSET uint8_t for a total of four bytes sent to the target from the host.

Writing a high byte to a Flash address is accomplished by issuing 48 SEGMENT OFFSET uint8_t for a total of four bytes sent to the target from the host.

Physically writing the low and high bytes to the flash from the buffer is done by issuing the "Write Program Memory Page" command which must be done per address location after having written the low and high bytes to a single address.

Locking the bytes into Flash memory can be done by issuing 4C SEGMENT OFFSET 00 for a total of four bytes sent to the target MCU.

Simply release the RESET line of the target MCU to end programming mode.

Example 40 00 00 FE 48 00 00 EF 4C 00 00 00 writes EFFE to address 0x0000 in Flash. Commands are issued one after another without releasing RESET, (which must remain low).


INTERPRETTING INTEL HEX FORMAT

Intel HEX format traditionally looks something like this: :107800000C94343C0C94513C0C94513C0C94513CE1

Understanding the bytes can be done by breaking each line of HEX code into groups like this:

:10 7800 00 0C94343C0C94513C0C94513C0C94513C E1

Each line in this bootloader example begins with a : representing the start of a new line.

The next two chars 0x10 from the example shows how many data bytes are in the line of text.

The next four bytes 0x7800 show the starting address where the code will be written to Flash with 0x78 as MSB or SEGMENT and 0x00 as LSB or OFFSET for the address.

The next two bytes 0x00 show that the next 16 bytes in the line are plain uint8 data. This will be written low byte first then high byte in that order until end of file.

Following the data type is a group of 16 bytes beginning with 0x0C ending with 0x3C 0x0C will be written as the low byte using ISP command 0x40 at address 0x7800 0x94 will be written as the high byte using ISP command 0x48 at address 0x7800

Then these bytes are locked into place inside the Flash using ISP command 4C 78 00 00 reflecting the address of the bytes that were issued to the buffer.

0x3C will be written as the high byte using ISP command 0x48 at address 0x7807 This is because the ATmega328(p) holds two bytes per address in Flash unlike the hex file shows.

The last two chars 0xE1 are the checksum digits for the entire line which can be discarded.

The last two lines in the hex file can be ignored as they will not be written to Flash in any shape, way or form. The last two lines of code look something like this: :040000030000780081 :00000001FF

They are not used for AVR, but used for storing instruction and stack pointer addresses in Intel x86 CPU's. The last line marks the end of file which can be ignored completely.

** Write the low byte, then write the high byte and then lock the bytes into place before writing any bytes to any other address ** ** The only address we are interested in is the very first address listed in the hex file, 7800 in this case for bootloader ** ** No other address should ever be used as the other addresses do not line up to how the data needs to be written to MCU Flash! **


BOOTLOADERS

ATmega328(p) has four bootloader locations inside it.

They are:

BLS1 - 0x7E00 - 0x7FFF size 0x0200 or 512 bytes

BLS2 - 0x7C00 - 0x7FFF size 0x0400 or 1024 bytes

BLS3 - 0x7800 - 0x7FFF size 0x0800 or 2048 bytes

BLS4 - 0x6FFF - 0x7FFF size 0x1000 or 4096 bytes

Per the example above, this bootloader begins at 0x7800 so we know we'll have to use Bootloader Section 3, BLS3. This will be the start address where the bootloader code will reside.

However, all Application Code should be written starting at address 0x0000 inside the MCU Flash without entering bootloader space unless the bootloader option is disabled.

Disabling the bootloader can be accomplished by setting [BOOTRST] to 0 which will set the Reset Vector address to 0x0000 during Power-Up.

This way, the bootloader is disabled and your Application Code will still work.

Disabling the bootloader will give your Application Code more space as it can then fill up the bootloader sections since execution starts at 0x0000.


@Iexpress, you appear to have posted the same post to lots of different threads.

I like the idea of the bootloader to set fuses, then use an ISP to over write. However, is there a faster way to set fuses, and then use ISP to burn chip?

ChilliTronix: Well, I have some test 20X4 LCDs that I can't sell, and some other bits I also can't sell, so why not make a programmer that will allow me to sell an equivalent to the Shrimp kit in both 328 and 1284 format?

I have used the 20x4 LCD and it was very good, I found. I'll have a look at what I paid and let you know as it might well be that the if you can sell at the price I paid they may well sell. Back in a touch.

Crikey I bought the buggers off you, sorry about this hiccup. So your price can't be too high for a stingy old rat like me to buy one, maybe people want the TFT., type now a-days somewhat similar to that which has happened to 7 segs that have just about gone to the wall except for the odd usage.

Chris

ChilliTronix: @Iexpress, you appear to have posted the same post to lots of different threads.

O' Chilli! Who's a naughty boy then.

Surely just as in my old Microchip history you can set all these AVR register factors in the program language (instruction set) at start up. Is there any real need to have separate boot loaders? Probably just as hard to remember which bootloader for which application especially 2-3 hours after you have written the app., code than it is to set the required registers in the actual project program code.

Chris

db2db:
I like the idea of the bootloader to set fuses, then use an ISP to over write.
However, is there a faster way to set fuses, and then use ISP to burn chip?

Is that tongue in cheek language otherwise that sounds a bit counter productive if I may say so.