Flash erase works in debug mode, fails in standalone

[giovanito]

DSP 568037

My application is designed to read and write configuration data into internal flash.
It unlocks global protection, erases the desired sectors, then writes.
The space reserved for that is from 0x7700 to 7AFF; the application does not occupy this area.
For example,
    IFsh1_SetGlobalProtection(FALSE);
    IFsh1_EraseSector(0x7700);

Everything works fine in debug mode, using USB TAP.
When running alone, it doesnt work and the process hangs forever inside the IFsh1_EraseSector method, more precisely in the internal procflash method, without returning any error code.

I'm using codewarrior ver. 6.2

Following are the IFsh1:intFLASH bean parameters:

Write method: write
interrupt service/event: Disabled
Wait in RAM: yes
Virtual page: Disabled

[J2MEJediMaster]

Watchdog disabled or fed?

---Tom

[giovanito]

Yes, WDog is active and fed.

Thanks to your hint, I further investigated WDog functionality, and found there actually are problems also with WDog; don't know how much they are related with the IFsh1_EraseSector problem.

The anomalies we see about WDog are:

A1) sometimes WDog fails in debug mode: instead of resetting, it triggers the MisalignedLongWordISR function, and the stack list appears messed up with nonsense.

A2) sometimes WDog fails also in standalone (no debug) and is not able to reset from a dead loop; the system permanently locks; 100% sure it's not fed under interrupts.

The anomalies we see about the IFsh1_EraseSector problem are:

B1) the IFsh1_EraseSector function fails in standalone (no debug) and the system locks. In debug mode, it NEVER locks, and always works correctly.

B2) the IFsh1_EraseSector function fails and locks even when the flash global protection is active, i.e. without prior call to IFsh1_SetGlobalProtection(FALSE). It's supposed to return an ERR_NOTAVAIL; this shows that it locks inside the call to Run_and_wait_in_RAM inside the procflash internal function.

B3) sometimes WDog fails to reset a lock caused by IFsh1_EraseSector; this may happen even when the problem described in point A2 is not showing, i.e. succeeds to reset from a dead loop but fails to reset from IFsh1_EraseSector.

I must point out that we use the .cmd file to keep the linker from using the data portion of flash. The sector I am trying to erase with IFsh1_EraseSector is far outside application area. We also have a static bootloader. To preserve flash from being mass erased when programmed by USB TAP in debug mode, we added a "set_hfm_erase_mode pages" command to file 56803x_flash.cfg in /support/initialization.

Thanks for attention !