Looking at the datasheet:
14.3.4.5 Watchdog Reset The Watchdog Reset is entered when a watchdog fault
occurs. This state lasts 3 Slow Clock
cycles.
When in Watchdog Reset, assertion of
the reset signals depends on the
WDRPROC bit in WDT_MR: If WDRPROC is
0, the Processor Reset and the
Peripheral Reset are asserted. The
NRST line is also asserted, depending
on the programming of the field ERSTL.
However, the resulting low level on
NRST does not result in a User Reset
state.
Could it be that the watchdog is firing and driving the reset line?
If your filesystem is read-only, use ext2. That is proven stable for several decades, is fast, efficient, supports ownership, supports permission bits and has a huge user base as every Linux box supports it. In other words it supports everything a decent Linux system requires.
If read-only is not an option, your next best bet is ext3. Apart from all the properties that ext2 comes with, ext3 brings journaling. This means that every change on disk is only committed once it has actually been written to disk. Very stable, proven technology. A problem with ext3 is wear leveling.
Ext4 improves on performance in several use cases, but comes with more CPU overhead. Most distributions today default to ext4. Apparently it reduces unnecessary writes, which is good for an SSD. Ext4 has a TRIM extension.
Next in line it BTRFS. Don't go there. Although several distributions offer BTRFS or even default to it, it wasn't stable last time I tested it (H2 2012). You don't want to use a filesystem that hasn't proven itself under stress. Too many bugs are being fixed.
Linux offers a wealth of filesystems, but the ones I mentioned above are the most common ones.
Of course there is FAT32 (vfat), don't go there. It is old, it suffers from fragmentation and doesn't allow for ownership and file permissions.
NTFS is closed source, don't even think about it. Yes it kinda works on Linux but the implementation is fully based on reverse engineering (because Microsoft doesn't release any technical details) and the Linux implementation is just not reliable.
A JFFS2 needs to be entirely scanned on a mount, so mount time increases linearly with device size. This is caused by the fact that there is not some sort of tree structure to store files.
Best Answer
This depends on the design. To dump contents of the flash chip it must be powered, and the driving device (driving outputs) on the PCB must be in high impedance (Hi-Z) state. If you have flash connected to the processor directly and you are sure, in reset condition, having consulted its datasheet, that it will pull all flash-connected/related signals to Hi-Z, then you will be able to dump the flash easily. However if there's any active buffer device in between which is not going to Hi-Z on reset condition you will not be able to perform the dump.