st demo code STM32F4-Discovery board causes breakage

[anarchitech]

... with loop execution when chatting w/ target (kernel-itc loaded into ram.)

This is due to the watchdog timer being set.

Example of issue

cd ~/muforth/mu
./muforth -f target/ARM/board/stm32f4-discover.mu4 ram -f target/ARM/v6-m/kernel-itc.mu4
jtag
ram
hex
: w 0 do loop ;
100000 w    <--- hangs, chat lost with target

Workaround

Wipe out the factory vector table. The following also sets GPIOD up so you can "do your own thang with der Blinken lights."

First, save the factory flash image just in case you later decide you had an emotional attachment to it or for later study:

cd ~/muforth/mu
./muforth -f target/ARM/board/stm32f4-discovery.mu4
@flash 4590 read-image
save-image fileName.img

...this will automagically save fileName.img in ~/muforth/mu/

Next, replug the board and run the following:

cd ~/muforth/mu
./muforth -f target/ARM/board/stm32f4-discovery.mu4 ram -f target/ARM/v6-m/kernel-itc.mu4
jtag
ram
hex
0 t.erase
ff RCC_AHB1ENR !
55000000 GPIOD_MODER !

You can create a custom loader file anywhere you like to handle initiating chat with the target and getting it set up to do something useful with the GPIO's. Canonically the assumption is made that you would create it in muforth/mu, but then canonically the assumption is made that you would work inside ~/muforth/mu and type ./muforth everytime you wanted to fire it up. Some of us like to just have a bin/ directory in $HOME and symlink muforth from there so we can just type 'muforth' and be on our merry way from wherever the hell we are. It's your sandbox, do as thou wilt. In the following example, we will use the canonical assumptions because it's canon, damn it.

loader.mu4

ld ~/muforth/mu/target/ARM/board/stm32f4-discovery.mu4
ram
ld ~/muforth/mu/target/ARM/v6-m/kernel-itc.mu4
jtag
ram
hex
ff RCC_AHB1ENR !
55000000 GPIOD_MODER !

If you want all the GPIO's configured as outputs OOTB, then just change 55000000 to 55555555.

To load:

cd ~/muforth/mu/
./muforth -f loader.mu4