Beken: zero PS_DEEP_CTRL_PARAM before entering deep sleep

[EinsEins11]

While getting deep sleep working on a BK7238 battery sensor, timed wakeups behaved randomly: PinDeepSleep 20 came back after ~7 s, and DeepSleep 5 never came back at all - the device had to be power-cycled, and twice, because Beken deep sleep survives a short interruption.

PS_DEEP_CTRL_PARAM has nine fields:

UINT32 wake_up_way;
UINT32 gpio_index_map, gpio_edge_map, gpio_stay_lo_map;
UINT32 gpio_last_index_map, gpio_last_edge_map, gpio_stay_hi_map;
UINT32 sleep_time, lpo_32k_src, sleep_mode;

Both call sites declare it on the stack and fill only a few. Everything else is whatever happened to be on the stack - including:

• lpo_32k_src, which selects the RTC clock source for the timed wakeup. A random value here is exactly why timed wakeups fired at arbitrary times.
• gpio_stay_lo_map / gpio_stay_hi_map, which pin GPIOs to a fixed level during sleep.
• gpio_last_index_map / gpio_last_edge_map, extra wake sources for GPIO32-39.

CMD_DeepSleep() additionally leaves the GPIO maps garbage, and PINS_BeginDeepSleepWithPinWakeUp() leaves sleep_time garbage when called without a timer.

Zeroing the struct fixes it, and the zero defaults happen to be the right ones: empty stay/last maps, and lpo_32k_src = 0 = LPO_SELECT_ROSC, the internal oscillator, which is present on every board (a 32k crystal may not be fitted).

Tested on BK7238 (T1-U-HL). Before: PinDeepSleep 20 woke after ~7 s. After: commanded 30 s, actually slept ~31 s. GPIO wakeup also became reliable, and both sources work together - with a 600 s timer armed, a knock on the accelerometer woke the device after 4 s.

[github-actions]

🎉 This PR is included in version 1.18.306 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀