-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/15/2012 01:12 PM, Jan Kromhout wrote: > Dear Alaric, > > There is a working version in the download of the 4.8 version. > I have try this one before I started to compile my own running version.
The one from the 4.8 zipfile works for you? Damn... it must be a problem with my hardware, then :-) Exactly what hardware do you have? I have an Arduino Uno, which uses the same CPU (ATmega328p) as the Duemilanove; the readme.txt in the appl/arduino directory suggests I use the duemilanove.hex and corresponding EEPROM, along with the suggested fuse settings. The duemilanove.hex from amforth-4.8.zip *almost* works; I get a nice prompt, but it's easily crashed. I think the fact that "words" works but prints a mixture of garbage and names of words to the screen (always exactly the same garbage) is telling; it feels to me like the dictionary is somehow corrupted. The flash files flashed perfectly to the AVR, and verified back, so my first thought was a problem in the .hex file, perhaps snuck through if it was just automatically built as part of the 4.8 release but hadn't been tested. I wanted to do my own build with avra to test this hypothesis, and also to give me a base to work from in diagnosing the problem - if my own build did exactly the same things, I could extend TURNKEY to call WORDS, perhaps put a small delay in the loop that prints the words in case the corruption is actually a serial problem caused by the high speed, and work from there. But getting a build with avra required me to update to the latest svn release of amforth for various reasons, and the resulting code didn't even get me to a prompt... I think I see two paths going forwards: * Dig out a Windows system (or WINE?) and run AVR Studio and thereby get the official AVR assembler running and try building form the 4.8 release sources, check I get an identical resulting .hex/.eep.hex file, and then add diagnosis tools to it and investigate from there * Sticking with my avra setup, write my own device tests in assembly (checksum the contents of flash, saturate the serial port, and so on), and/or put debugging code into COLD and WARM and friends that will flash the LED on the Arduino board in different patterns, so I can see where the avra-built hex file hangs by seeing what the last pattern I see flashed is. > If this is not working I will send you my running version. Any known-working .hex and .eep.hex files I can try will be gratefully recevied, as even if they don't work for me, how far they get may give me useful clues :-) > One thing, I have bought the mkii programmer, and after that I got a running > by my own compiled version. Mine's a USBtinyISP. I built it myself from a kit, so it's slightly suspect (it might not be working properly), but the fact that the flash and eeprom and fuses read *back* correctly for verification makes me think it's probably OK. Thanks for the response :-) ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/bMjoACgkQRgz/WHNxCGr10ACfSCn9acfKuJFmND+DuejNnTH1 /sMAn1vLuYN/jWFPzhe2i78hH8QLkyf5 =J6Sa -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
