From: pito <pi...@vo...> - 2010-09-30 18:42:26
|
Hi, this is a short story on how I've found a bug in an asm word. After few days of experimenting at amforth level I decided either to start with other hobby or to find out how to simulate the whole stuff and see what is actually going on by stepping via the avr flash code. The experiments with AVR Studio - mainly simulation at asm level finished with an early crash. By chance I found the crash is caused by the debugger - when the asm source wants to continue into a "debugger" (for the code outside the "amforth.asm") the debuger is called, but not set properly (my understanding) and crashes. Now, how it works: 1. compile amforth in AVR Studio as usuall 2. then close all projects 3. open file - e.g. amforth42_1284p.hex (MUST BE .HEX) 4. Studio offers a new project name e.g. amforth42_1284p_hex.aps - do save 5. select device and debug platform (simulator2 and 1284p) 6. finish 7. debuger opens and you will see the flash disassembled 8. then go Debug -> Up/download memory, choose EEPROM and load eeprom from file e.g. amforth42_1284p.eep, open memory watch window and select eeprom - you will see the eeprom content 9. TERMINAL - I did not find terminal in AVR Studio, so I downloaded HAPSIM for AVR Studio: download, run hapsim.exe and do file -> New Control -> Terminal, it will connect to AVR studio, you may set settings 10. Place breakpoints where you want (here you see entire flash disassembling only, so help yourself and open .lst file and navigate accordingly) when not keen on stepping via all code there 11. when you Run the debuger you will see after few seconds amforth's hello and promt in the Terminal, you may work as usual (mind the respones are several seconds) and you may step via the flash. I did not try to upload a new word, but I ran existing word and watched what is going on. It help me to find the bug - otherwise I would not find him by today.. I would be happy to know your experience with amforth debugging/simulating as well. Pito. |