Bug while changing modem mode from "data" to "command" (IDFGH-7502) about esp-protocols HOT 9 CLOSED

@bbinet Yes, this seems to be a bug, as when the device fails to switch mode, the mode should go to Unknown:

 if (!device->set_mode(modem_mode::COMMAND_MODE)) { 
     mode = modem_mode::UNDEF:
     return false; 
 } 

I can also see that switching modes could be improved, this haven't been thoroughly tested with many devices, but in general it misses some retry mechanism when sending the escape sequence of +++.

Moreover, if you're using the C-API, it doesn't seem to return this failure, so even users couldn't implement a retry.

Will address these 3 problems.

from esp-protocols.

Thank you @david-cermak.
Also do you know why device->set_mode(modem_mode::COMMAND_MODE) always fail for me whereas the mode actually seem to have correctly been changed to command mode as I'm able to send AT commands successfully.

from esp-protocols.

Also do you know why device->set_mode(modem_mode::COMMAND_MODE) always fail

Does it always fail?
My guess is that your device perhaps needs more time to respond, or a delay before sending the command or something similar. Switching modes is very tricky and very much depends on the actual device. I haven't tried working with the BG95-M3 device. (according to the docs on +++ command: we should retry after 1 second period, until we succeed...)

from esp-protocols.

I'm not sure about always but I don't remember of a successful switch from data to command mode.
Does it work for a BG96 module?
I can test with longer timeout, but as I'm not used to C++, can you indicate where is the implementation of the device->set_mode() method for the BG96 device?

from esp-protocols.

Yes, it works for BG96

The command to exit (escape) PPP mode is implemented here

from esp-protocols.

@david-cermak when I try to log return value at

This is weird as if I connect a serial port directly to my bg95-m3 modem, and I manually send command +++ to switch mode from data to command, I immediately get the response "NO CARRIER", so I should not have a timeout when communicating with the bg95 module through esp_modem.

from esp-protocols.

I've tried to add some additional logs to understand why I get a timeout, and in the mean time I've connected the RX line of an additional serial port to the TX line of the bg95 module to act as a sniffer to see its response in realtime.

I've added the following logs:

• "set_read_cb" after line 40:

  esp-protocols/components/esp_modem/src/esp_modem_dte.cpp

  Lines 40 to 41 in 2a4e684

  	command_term->set_read_cb([&](uint8_t *data, size_t len) {
  	if (!data) {

• "command_term->write" after line 57:
  

  esp-protocols/components/esp_modem/src/esp_modem_dte.cpp

  Lines 57 to 58 in 2a4e684

  	command_term->write((uint8_t *)command.c_str(), command.length());
  	auto got_lf = signal.wait(GOT_LINE, time_ms);

Then when I switch the mode from data to command, I only see the log "command_term->write", but not "set_read_cb", whereas I can see the "NO CARRIER" response on my additional serial sniffer.

Any idea why the set_read_cb callback is not called?

from esp-protocols.

Any idea why the set_read_cb callback is not called?

Does your serial sniffer show the newline characters (\r\n) after the NO CARRIER response? That could be the reason why the lambda doesn't get called. I'll try to reproduce it.

from esp-protocols.

@david-cermak I confirm that your PR #52 fixes this issue on modem BG95-M3: I can now successfully switch from data to command mode.
Thank you!

from esp-protocols.