This page is for developers only. Using ISP is NOT needed, causes unnecessary complications and inconvenience, and NOT supported (also voids warranty)
MegaTune distribution has .bat "batchfiles" that help with the firmware upgrade. Check any associated README.txt files or the .bat-s themselves.
Reflashing firmware might destroy the config so make sure you have a config at hand to upload after the firmware upgrade.
- If you have no uptodate config (eg. config.txt file lost from the PC; or many changes through MegaTune), save old configuration and tables from TerminalProgram, with (Man) mcd and mct commands. Save the output as etc/mcd.txt and etc/mct.txt.
- You can normally just copy etc/mct.txt to etc/tales.txt (usually no changes there)
- and copy etc/mct.txt etc/config.txt and edit to your needs. There are occasionally minor config changes (1..2 variables per release) as on GenBoard/UnderDevelopment/FirmwareChanges (can be several variables if jumping a bigger firmware version step, but usually no big deal. Ask for confirmation when unsure about some values).
After the new code is in place, restore the config:
See GenBoard/InitialConfig for initial configuration.
Uploading bootloader via ISP cable
Easy to follow instructions contributed by patient users: see MembersPage/MattiasSandgren/NickesBMW/AvrBootCode - thanx !
Using ISP is normally not necessary. Only if a damaged board ain't want to talk in serial. In the future, there might be a procedure to upgrade to the networked bootloader. Uploading via serial is possible (or not) depending on an internal lock-bit.
- lock=3f allows upgrade via serial
- lock=2f does not allow upgrade from serial => in this case it can only be done through ISP cable
- lock=3c allows upgrade via serial and this is the best value finally (allows upgrade to new bootloader).
- Strongly recommended to set this value, but only after verification of written flash-data (but no worries: chip-erase erases lock to 3F to start everything from fresh)
Uploading the [bootloader] or firmware (or even both at the same time, if one manually merges the .hex files, removing the short 1ff "ENDLINE" from the first) is really easy.
You can construct a device for 1 Euro in about 5 minutes from a DB25 male connector if you have a PC with parallel port.
- It's called STK200 cable (also possible with buffer chip, or just with wires - but make it short, like 15..35cm ). STK200 cable is documented in avrdude configuration file: avrdude.conf, ( [old snapshot copy with some notes]
We use the STK200 cable with uisp and avrdude.
This [nice little USB programmer] was also tested with avrdude (on windows) with atmega 128. Works well.
This is great news. For motorola you need a $65 ($49 programmer + $16 adapter for processor) equipment or send your board to some of the kind people who can program it for you (and you need to mess with a socket).
asking for help regarding BootLoader boot/main.c upload
I usually upload bootloader via avrdude (see bin/mintest.sh). However I'm not satisfied:
- avrdude sends 128kbyte instead of just the upper 2 kbyte (ideas?) Tried UISP?
- we store 12 bytes identity word in flash, at the end of bootloader, below the bootjump: (byte address 0x1FFF0..0x1FFFB ?)
- board serial number (board version can be found out)
in the future: (bin/patch_identity.pl script)
- board assembly variant (flags: knockchip, etc...).
- maybe calibration data would also be useful (hard to fit if bootloader is kept in 2 kbytes .. maybe on a page below ).
If you choose to diverge from what most of us use, or over-curious here are some links:
- [[Manual: Detailed.Central.Firmware.Install]]
- After you have compiled your firmware (you read GenBoard/Firmware/BuildFirmwareFAQ )
- google: atmel isp programmer parallel
- http://www.freeweb.hu/vfx/avr/index.html another description about a simple programmer Hungarian, with graphics
Atmega168 ISP program upload
With a smaller HW (not GenBoard, but a related LED display), we want to upload program to virgin atmega168 uCs (no BootLoader yet, that's exactly what we want to upload: ISP upload is needed, which is not supported by avrprog). Preferrably programming process should work on linux and win32 too.
avrdude avrdude works for MembersPage/MarcellGal on win32 too. (a bit annoying that avrdude uploads 128kbyte whenever we write BootLoader to the upper 2 kbyte location. No big deal, we used avrdude traditionally for virgin genboards).
Avrdude supports Atmega88 since ages. I modified avrdude.conf for atmega168, according to the datasheet
- flash size and pagesize
- added a12
- added a5 to some places, and deleted from other places (since pagesize changed from 32 to 64 words).
It seems to work, will be commited to SubVersionSVN. We should contribute ?
Avrdude annoying bugs:
- does not handle the holes in hexfiles. Takes longer to execute (eg 128kbyte instead of 2kbyte). Also, it gives false alarms when it finds mismatch in the part it shouldn't verify at all.
- One of the avr-binutils will do the trick. "avr-objcopy.exe" Located in WinAVR\bin. To use:
avr-objcopy -F ihex --gap-fill=0xff infile.hex outfile.hex
- I tried it, and indeed it fills the gaps with all ff. Therefore it doesn't do what is needed:
- First, if there is (2kbyte bootloader) code from 0x1F800 to 0x1FFFF it doesn't fill the "gap" from 0x0000 to 0x1F7FF (unless there is something at the beginning of the hex, which there is not => could be hacking in, but even than not a solution)
- we don't want to upload anything to the unused sections. We want them to be skipped
- for better upload speed
- and proper verification. If the gap in the hexfile is filled with anything, avrdude will not be able to verify properly (=> will fire a false alarm, seeing the firmware different than the gapfill FF in the hexfile).
- does not warn when hex file has a closing (01FF) record, and more data after it
- syntax was changed for the bad that broke old scripts (probably undoable)
uisp only works well for MembersPage/MarcellGal on Linux only
http://savannah.nongnu.org/projects/uisp/ the 20050207 version also adds support for AtMega88 and AtMega48 (note: NOT atmega168), and it's compatible with g++-3.4 => We hacked atmega168 support that seems to work.
- http://lists.gnu.org/archive/html/uisp-dev/2003-05/msg00000.html on win32 it says "/dev/parport0: No such file or directory Failed to open ppdev."
- http://www.kanda.com/~support/Avrisp3.x.zip - This is a very easy to use download program for AVR's. The hexfile editing is a nice feature.