Hi @HLy ,
Please refer to 3.9 USB CDC feature (page 1063) in AT_Command_Interface_Guide.pdf to Enabling the USB Port and Disabling the USB Port
Enabling the USB Port
To activate the USB feature, in CDC mode, the application must send the AT+WMFM=0,1,3
command to the embedded module. The embedded module replies:
• OK if the USB stack successfully started,
• +CME ERROR: 3 if the USB stack failed to start.
From here there is 2 possibilities:
1 – The embedded module is wired to the host, the device enumeration is done: if the enumeration
is successfully completed, a VCOM and a embedded module device (viewable in the devices
manager) are created at the host side otherwise the failure is notified to the user (by the host).
2 – The embedded module is not wired to the host: the USB stack is waiting for the USB cable
plugging. As soon as the cable is plugged, the enumeration stage described above starts.
Disabling the USB Port
To deactivate the USB feature, the application must send the AT+WMFM=0,0,3 command by using
either the UART1 or the UART2.
Two cases are supported:
1- The USB stack is running in CDC mode: if the stack is stopped successfully, the embedded
module replies OK, otherwise it replies ‘+CME ERROR: 3’ (note the USB stack is still running
in CDC mode).
2- The USB stack is stopped: the embedded module replies unconditionally ‘+CME ERROR: 3’.
An embedded module reset, whatever its origin, stops the USB stack. If the user has saved the USB
CDC configuration in EEPROM, the stack will be restarted while the embedded module is rebooting.
Stopping the USB stack and then disabling the CDC device implies that the VCOM and embedded
module are getting unavailable at the host side. The applications using these resources must be
closed since the piece of software drivers they are using no longer exists.
If the issue is solved, could you help to mark “Solution”? So that the community can easily find the solution for their problems.