W32K mode and unsolicited messages


(I’m not sure if the right forum is SL6087 or here).
We need the W32K mode for our application. We do what we can to activate it, but the SL6087 only switches “when it wants to”. It took me quite a few weeks to figure out that one of the problems is unsolicited messages being sent on UART2.
When the port is in DATA mode (as opposed to AT mode, or closed), the messages are simply buffered “somewhere” and prevent the module from entering W32K mode.
Now that I’ve figured out what’s going on, I’m intercepting all unsolicited messages (with
adl_atUnSoSubscribe("+",TheUnsoHandler); ) and only print them on UART1. It seems that now, the W32K mode is entered as it is supposed to.

The question is, isn’t it a bug that should be fixed? Some buffered yet inaccessible messages should not prevent the W32K mode from being activated.

Which port are you sending the command on?
You should use the internal virtual port and not UART1 for example, if you’re trying to use the command from within an OpenAT application.


Hello Rex,

in fact, I am not sending any command at all. This is about unsolicited messages (+WIND, +CUSD, +CREG etc.). When UART2 is in data mode, these messages are buffered, and prevent the W32K mode from being entered.

The AT+W32K=1 command, as well as all others, are sent using the internal port.

Thanks for the thread milan

I’m encountering a similar issue with the SL8080: https://forum.sierrawireless.com/t/uart1-buffer-preventing-w32k-mode/7707/1