_ _ | \ | | | \| | | . ` | | |\ | |_| \_|
### ### ## ## ## ## ## ## ## ## ### ##
_______ ( ___ ) | ( ) | | (___) | | ___ | | ( ) | | ) ( | |/ \|
_____ ( _ ) | ( ) | | | | | | (('\| (___\_)
## ## ##### ## ## ## ## #####
IMPORTANT: enter the case-INsensitive alphabetic (no numbers) code AND WRITE SOME SHORT summary of changes (below) if you are saving changes. (not required for previewing changes). Wiki-spamming is not tolerated, will be removed, so it does NOT even show up in history. Spammers go away now. Visit Preferences to set your user name Summary of change: '''This page is for developers only''' Users check out GenBoard/UnderDevelopment/FirmwareChanges and BootLoader (that reflashes firmware via serial connection). 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 (depending on config structure changes) 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: * make mtt (this makes .mtt from the .txt files) * and dump the etc/tables.mtt, etc/config.mtt files to the board with a TerminalProgram. See GenBoard/InitialConfig for initial configuration. ---- '''Uploading bootloader via ISP cable''' This 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, which is possible (or not) via serial depending on an internal lock-bit. (lock=3f allows upgrade, lock=2f does not => in this case it can only be done through ISP cable) Uploading the firmware 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 wire - but make it short, like 15..25cm ). STK200 cable is documented in avrdude configuration file: avrdude.conf, you can find a copy at: ** http://www.x-dsl.hu/genboard/programmer.txt Marcell's old notes on the programmer cable I built for uisp. We use the STK200 cable with uisp and avrdude. ---- 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). http://www.futurlec.com/MotorolaProg.shtml ---- '''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? '''other notes:''' * 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: * [http://www.vems.hu/manual/Detailed.Central.Firmware.html#Install [Manual: Detailed.Central.Firmware.Install]] * After you have compiled your firmware (you read GenBoard/Firmware/BuildFirmwareFAQ ) * google: atmel isp programmer parallel * http://www.cs.berkeley.edu/~awoo/smartdust/cable.html * http://bray.velenje.cx/avr/ * http://medo.fov.uni-mb.si/mapp/uTools/uisp-parport-connect.txt * http://wiredworld.tripod.com/tronics/atmel_isp.html * http://www.xs4all.nl/~sbolt/e-spider_prog.html * http://www.burnill.freeserve.co.uk/atmel.htm * 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: <code> avr-objcopy -F ihex --gap-fill=0xff infile.hex outfile.hex </code> * 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. Optional: Add document to category: Wiki formatting: * is Bullet list ** Bullet list subentry ... '''Bold''', ---- is horizontal ruler, <code> preformatted text... </code> See wiki editing HELP for tables and other formatting tips and tricks.