Hi,
Recently, i uploaded one of my rak3172 module from RUI 3.5.3 to RUI 4.0.0 version with ST-link and STM32 cube programmer. Since i use Atmega 328PB at 3.3 V and 8 MHz internal oscilator (which is not performing well at baud rate 115200), i use baud rate 9600 to communicate with RAK modules (AT commands).
After uploading the new fw, and connecting to module via UART2 with baudrate 115200, i changed the baudrate to 9600 (with command AT+BAUD=9600). Everything looked ok until i restarted the module with command ATZ. Since this moment, i was unable to communicate with module at 9600 baud and i had to switch back to 115200. Tried several times, but same behaviour. Also, after modem power cycle, module was set to 115200 baud. It looks like the baud rate setting is not saved after module reset or power cycle. Other settings like ADR,CFM,DCS… were retained.
Then i did full chip erase and uploaded rui 3.5.3 fw (later also rui 3.5.4…) and everything worked as expected, baud setting was retained after power cycle or reset.
I also tried rui 3.4.11, but same behaviour as rui 4.0.0, after each reset/power cycle, the previous baud setting is lost and 115200 rate is used instead.
This is a known bug with RUI3 V4.0.0. A bug fix is at the moment in our test and quality center and we will release soon V4.0.1 which has the problem fixed.
You can find changelogs and the lates firmware versions in our Download Center
Is it possible to say when we can expect the new fw will be released?
Maybe, one more question: since i have already soldered modules on PCB with direct signal paths to MCU via UART2, is it possible to create a custom hex file with baud rate already set to 9600? for example with this approach:
No release date available, but it is with highest priority, because we have multiple customers with the problem.
Custom hex file of default firmware with 9600 Baud preset is not possible.
Only option (and that will work even with RUI3 V4.0.0) is to create an empty custom firmware with the RUI3 API and force the baudrate to 9600:
void setup(void)
{
// Force Serial to 9600 Baud
Serial.begin(9600);
}
void loop(void)
{
// No need for the loop, kill it
api.system.scheduler.task.destroy();
}
This should work, but I did not test it.
Then flash that custom firmware hex file with STM32CubeProgrammer.
AT commands will work as before (they are integrated in RUI3 API), LoRaWAN stack is the same.
I created custom fw with forcing serial to 9600 baud, then i flashed a few of my boards with .hex file. They have been working without problems so far, so we will see.
The tricky question now would be: is this better solution (custom fw with rui 4.0.0) compared to previous fw with rui 3.5.3 ? What would you say? (i really need to send a few boards to my customers…)
