Hi Eduardo
I note that you originally had some difficulties programming the boot loader and the application with your demo board - this may be signalling a problem with the hardware (?).
Watchdog - if the routine were to hang for some reason (like forever loop) I would certainly expect the watchdog to fire as long as it is active (check that it is really active in your project (define CONFIGURE_WATCHDOG in app_hw_m5223x.h) and also that it is not being disabled by pulling IRQ4 low on reset (with active watchdog it is not possible to work properly with the debugger and so this technique allows debugging)). If the watchdog fires, the NMI
_sw_wdog_timeout() should immediately command a hardware reset - since the code seems to be looping somewhere I don't expect that this function can somehow be blocked.
Assuming that the code is looping in or around the
fnFlashNow() can you see where this function is being called from (is it looping there)? If there were problems with FLASH operations you may be able to see that the return value is not 0 (expected value in CFMUSTAT) - if this is non-zero can you see which bit is being set?
When you comment the function fnRAM_code() no FLASH accesses are made so this does suggest that there is something not operating correctly with the FLASH itself(?).
It may also be interesting to load the reference code to your board (
http://www.utasker.com/software/software.html) to see whether you have also unreliability when modifying parameters. As far as I know there have never been any difficulties encountered with this code so it may help to determine whether it is hardware releated or due to the present software version (or compiler?).
I hope that you can find out why this may be.
Regards
Mark