Application
-------------
I am using ATSAM4LC8B in a custom hardware. Application is using:

1. AST timer running on 32KHz, interrupting every 8ms
2. An external interrupt every 5ms (EIC 1)
3. Another external interrupt at variable times (EIC 2)
4. Using DFLL 48MHz, High Speed Flash Enabled, CPU & PBB divider set to 0 and PBA, PBC, PBD set to 2.
5. Using ASF library and that sets flash wait state to 1 and Power save mode to 2.
6. Application does very small tasks only on interrupts and otherwise is in WAIT_MODE (Deep sleep).

I am using the "bpm_sleep(BPM, BPM_SM_WAIT)" function to put the board into sleep mode.

Problem
----------
There are 2 probelms that we are seeing and they both could happen anytime from few hours to many days after having run this long without any issues at all.

1. The first problem we are seeing is that some times the boards get into a Hardfault_handler some where within "bpm_sleep" just after/at WFI instruction. This can happen anywhere from few hours to many days after having run fine without any issues. I have tried to get register dump in the hard fault handler but the relevant values do not make any sense. For example, PC seem to have value outside of the memory map and this varies from board to board. All works ok if we do not use WAIT_MODE and instead either keep the processor awake or use SLEEP_3 mode.

2. The second problem is that we are some times seeing "Core Power up reset". Note that the core is powered from built-in regulator of the processor in Switching mode (VDDOUT->Inductor/Cap->VDDCORE) as per the reference design. Again, all works OK if we do not use the WAIT_MODE and instead either keep the processor awake or use SLEEP_3 mode.

We have spend days trying to debug and fix this problem, have checked that the sleep/wake-up procedures are as per datasheet and at this stage have run out of ideas.

Please could you give some suggestions as what might be wrong? Is there a relevant errata for this processor?

Make sure that all unused I/O pins are properly biased.
Abnormal microcontroller behavior often occurs when any unused I/O pin is set as input and is floating. If any unused pins are neither pulled-up nor pulled-down, set them as output at low level.