.. index:: mecrisp-unsupported-mcu .. _mecrisp-unsupported-mcu: .. Created mecrisp-unsupported-mcu.rst: Sat 8 Oct 2022 18:00:18 AEDT .. Full Path: /home/tp/mecrisp-unofficial-doc/mecrisp-unsupported-mcu.rst .. Author Copyright 2022 by t.j.porter .. Made by /home/tp/projects/scripts/makerst.sh -->/usr/local/bin/makerst .. license: MIT, please see COPYING Mecrisp* on a Unsupported MCU ============================= Installing Mecrisp* on a MCU family not listed in :ref:`Supported Hardware` can be difficult especially if the target shows no sign of life, here are some tips from Matthias Koch the author of all things Mecrisp to aid the process. The Problem ----------- This is for a MSP430 with 'Mecrisp' but the same techniques apply for other Mecrisp Arch's I'm sure. In fact this is the most common issue of all. :: I am trying to run Mecrisp 2.0.7 on a certain MSP430 chip and can't even get the Mecrisp "hello" message - the terminal is not responding . Techniques To Try ----------------- :: The problem you describe might happen when memory map is wrong or some old contents cause initialising the dictionary pointer in catchflashpointers.asm to fail. Can you narrow down by toggling a LED where it crashes before reaching the welcome message? Immediately after stopping the watchdog (first instruction - MSP 430 only), you set a pin direction to output, and place xor.b #ledpin, &P1OUT on different locations in the boot process. The reset entry point is in the chip specific code, "catchflashpointers" is run which may crash silently if something is slightly wrong with memory, then terminal is initialised in your own code and finally a message should be printed. If you reach terminal init after catchflashpointers, memory is fine. If you reach "message is printed" usually Forth is already up and running. Change the location, use multiple xor instructions and your oscilloscope, or use multiple LEDs, and you get an idea where the crash happens. If you cannot light up a LED at the beginning of the code, then something is wrong with your flash tool, probably, or the chip is defective. Alternative: Connect debugger and step through the code. I cannot help more without a glimpse of your source code and knowing which chip you actually target for. As you are using Mecrisp-Across for it I can only deduce that this is a classic chip without CPUX extensions, and given you are trying to port Mecrisp, it will have at least 16 kb of flash :-) Good luck! Matthias PS: You know that end of RAM is given +1 to be aligned? RamEnde equ 4400h ; End of RAM, 8 kb instead of 43FFh which will crash due to misalignment. .. seealso:: :ref:`Compiling a new kernel` and :ref:`Porters Guide`