Issue: After entering data transmission mode via at+set_config=device:uart_mode:1:1 it is not possible to exit
Setup: RAK4200 Evaluation board, RAK Serial Port Tool (windows partition), Custom C++ code (linux)
Details: I have written a C++ program for communicating with a RAK4200EVB using the open(), write() and read() Linux functions plus the termios structure (for handling serial devices).
The program has worked correctly, allowing me to send commands and receive responses, unfortunately, sending at+set_config=device:uart_mode:1:1 has seemingly locked the device in data transmission mode. Sending the “+++” command (without \r or \n) via write() has so far failed to unlock the device, as did any attempts with the RAK serial port tool or gtkterm.
I’m not very familiar with that module, but my guess is the problem is that this command was erroneous - the last argument should be a baud rate, not an index into a table of them. So it’s probably now stuck with a misconfigured UART.
Hopefully someone can give you some suggestion on a way to reset settings that doesn’t rely on the serial port working. From other posts it looks like reflashing via SWD could be a last recourse option but others will have to fill in the details and if that’s actually recommended.
You might also just try cycling the PC side through the listed baud rate options and see if you can get a response at any of them - perhaps it’s already protected against bad values and goes to some default. I’d fully disconnect it from the PC to make sure it’s been fully power cycled between each attempt.
By looking at the documentation for the module the command for switching to data transmission mode only asks for the UART port (first parameter) and 1 (to switch the port to data transfer mode).
As for the baud rate, i have been attempting to use CuteCom with various baud rates, delays and other settings but with no success, even after power cycling. Worst comes to worst i’ll go through the SWD route and attempt to work out the issue that way.
Thing is, i already have tried that, multiple times.
Both by using the linux open() function (making sure to only send the 3 bytes corresponding to the “+++” string, both as string literal and array of chars) and tools like cutecom and gtkterm, none of which bore any fruit. Perhaps i’m somehow using the wrong settings but that seems like a stretch as i have tried more or less any combination of settings in order to attempt to send such command and break out of the data transmission mode.
The terminal I use is coolterm. It is multiplatform (windows, linux, macos) so you can probably give a try. I am using Line Mode and Custom Sequence (empty) on the termination settings.
Just tried.
-installed coolterm, default setting
-clicked connection->options
-Serial Port: ttyUSB0, 115200 baud rate, 8 data bits, parity none, stop bits 1, no flow control checkbox selected, Software Supported Flow Control enabled, Block keystrokes while flow is halted enabled, dtr on, rts on
-Terminal: line mode, key emulation custom, custom sequence empty, all checkbox off except for convert non printable characters (default configuration)
returned to main window, connected and sent +++ first, then re-enabled CR+LF in terminal settings and sent at+version as a test, no response
ADDENDUM: the firmware ver is 3.2.0.12 (obtained by connecting to secondary UART pins and pressing the reset button, unfortunately could not run commands or the +++ string from it either) if that can help
ADDENDUM 2:
Using coolterm and connection to the secondary UART port i have been able to send at+ commands, unfortunately the UART1 port is still stuck in data transmission mode despite my best efforts. As such, the problem still persist
Sorry about the earlier confusion about command syntax
Does this need any surrounding idle time or anything?
Something I might try would be sending a CRLF (maybe even twice) before sending the “+++” possible with an intentional pause in between, with the idea that there might be line noise grunge sitting in the serial buffer confusing the parser - but then I don’t know how the implementation actually works.
I’d also make sure (maybe with strace?) that what’s being written is just the “+++” and no terminating null. Also make sure the port isn’t stuck in cannonical line buffered mode on the linux side. At some point a scope or logic analyzer on the wire could be interesting.
Is the mode stored in EEPROM that could be individually erased to revert to a default configuration? (IIRC ST’s windows based SWD tool can do that)
Ultimately at the end of the day, I think it’s probably smarter to have a program send explicit packet transmission commands, treating LoRaWan uplink like a serial pipe feels a bit undesirable to me, since it hides the fact that things are so different.
Update: attempts to flash a new firmware via UART ports have failed as well.
-attempted update through UART1 port->device firmware upgrade timeout
-attempted update through UART2 port->device firmware upgrade timeout
-used UART2 port to put device into boot mode and update through UART1 port->device firmware upgrade timeout, same result for UART2 port
The issue is thus, as of yet, unresolved (device still stuck in data transfer mode).
EDIT: using at+set_config=device:uart_mode:1:0 through UART2 the issue has (seemingly) been resolved (even if in a roundabout way).
Will do further testing to check if the “intended” method (the +++ string) works
