I have been working with the SAMB11 chip for quite some time now and I find that it can get quite unstable if you do anything more than the simple ASF examples. I have managed to get around a most of the ASF bugs, but the ULP and platform message functions seems to be breaking the SAMB11 in many exotic ways. The Microchip technical support guys seems unwilling or incapable of solving, or even explaining these bugs. Unfortunately, none of the workarounds they suggested worked in my product, so I am appealing to the greater community for help.
We are using the SAMB11 device in a portable device powered with a CR2032 battery. Because of the low power requirements, we are using the ULP functionality of the SAMB11. We have a Sharp Memory LCD connected to one of the SPI ports and a single wakeup button connected to the AON_0 port. We use the AON_Timer to periodically wake the SAMB11 on a 1 second interval in order to toggle the LCD VCOM line (This is a requirement to keep a latent charge from building up within the Liquid Crystal cell). The device will be in an idle mode most of the time, with only the AON_0 wakeup button and the AON_Timer enabled. The device will randomly crash anything from a few seconds to several minutes after the wakeup button is pressed for the first time. If ULP is disabled or "acquire_sleep_lock()" is called before entering the main loop, then the product will work for weeks on end, even running under heavy use inside a testing jig.
Note: I am aware of the bug in the ASF "button.c" code where they forgot to clear the "button_debounce" flag, but this is not related to our issue.
I have attached the source code for the test case that I submitted to Microchip and would appreciate it if anyone can comment on this. The code was written to run on the SAMB11ZR Xplained PRO board and will pulse the user LED to simulate LCD VCOM line in our product. For simplicity, I have not initialised the BLE stack or the AON_0 power button and have used as few other ASF functions as possible. You will notice the LED pulsing for a while and it will then stop when the SAMB11 crash.
There are actually many ways that you can *make* this code work, but you would just be masking the real issue. The code was crafted specifically to demonstrate the ULP bug we are seeing in our product. Without the SAMB11 kernel source code, I can only speculate about why this happens. I am however seeing a pattern, and in every case, this involves the platform message queue. Changing the "100" (1 second timeout) in the platform_event_wait function to "-1" will for instance cause it not to crash. This of course will disable timeout messages and change the whole scenario. Likewise, disabling the sleep timer function will also "fix" the problem.
We have encountered many similar issues when using platform messages, but in ways that are more difficult to repeat reliably. In some cases, simply moving a platform_event_post call a few lines down would solve an issue. Things have been much more stable since we implemented our own message pump. To get my product out the door, I had no choice but to disable the ULP function when activating the BLE stack. This unfortunately means way higher power consumption (4mA vs 3uA) when the device is active. On the positive side, I have not had a single SAMB11 crash in the last few weeks since selectively disabling ULP. Unfortunately, depending on use, battery life has dropped from an estimated 2 years to maybe less than 3 months.