AT+IPR does not stick

I configured the HL8548 module to 38400 and it operates at that rate at every power up now. However, if I attempt to reconfigure it to 115200, it resets back to 38400 on every power cycle after.

This is an issue in 5.5.14 and 5.5.23 versions of the firmware.

How do I save the UART Rate to 115200 for every power cycle on a device that was configured to something different using AT+IPR=38400?

AT+IPR=115200 does work for the session, but I want to keep it at that rate even on a power cycle.

Do I need to send AT+CPWROFF or something to get it to save?

Hello,
Which module are you using?

Regards,
Moderator

HL8548

It appears sometimes it will work, but other times it does not as I program ~200 of these.

Problem was pin-shorts in our level translators. CTS/RX and DCD/DSR were shorted in some instances and Flow control is switched on/off as needed with the module.

i.e. Seems everything is fine with the radio.

Hi,

We actually had similar problem with HL8548, with no hardware issue involved…
in production, we change the default UART1 speed to 460800 baud, then check the module properly understood the command by reading AT+IPR? and finally properly turn off the module using AT+CPOF, before cutting the module’s supply.
In spite of this, we were reported from the field that some MODEM do not communicate @ 460800 baud, but falling back the setting to 115200 baud makes the communication working. It is like the module did not save the last baudrate! Did anyone meet this issue? How to fix this annoying behavior?

We wound up just sending AT+IPR setting followed by trying to communicate with the module at the new rate by just sending AT and waiting for the OK response. If it fails after a few seconds, we then go back and try again.

After that, the module is left on for another few seconds (prior to programming our main application). That appears to work.

To save time, we incorporated this change into an image for updating the 8548 Firmware image.

So, it seems your are updating the modules FW? We don’t do such thing! Only thing we do once the module is tested is changing the default baudrate to 460800 using +IPR=460800 and then set +KSYNC=2,7 (so that network status is reported on a LED).
We do test back the proper execution of the +IPR command by testing at the new baudrate +IPR?
If the answer is +IPR: 460800, +CPOF is sent and power supplies are turned of.
Despite this double-check, some customer reported non-communicating MODEM for which, changing the Host baudrate @ 115200 fixes the problem… (it happened on ~2% of the products we sold)

We had to do a firmware update as we send large TCP packets from time to time and 5.5.23 fixed an issue where the module would reset from 5.5.14. Ever since doing it with some test code that just flip-flops between the two bauds, it has worked 100%.

The key it seemed was to just ping-pong from 115200 to the desired rate and checking if a valid response came from the new rate. Then keeping the module on for a period of time.

Interesting. Thank you for sharing your experience. Maybe we will try to just spend a few second more sending IPR? requests before we finally send the +CPOF command…

Regards,

I would recommend sending a few “AT” and check for a valid “OK” response. Then just wait a few seconds after that and it seems OK. I would not continue to send IPR commands.

OK, thank for your advice! We’ll try as you advise ; unfortunatelly, I don’t have any mean to tell you whether it worked for us in the short term…

Regards,

We have some modules (at least 8 units here on my bench) that have firmware 5.5.23 and they crash/reboot every time I send AT+IPR=115200 to them via the UART connection

I have tried AT+IPR=38400 or AT+IPR=57600 and can set this fine (over 100 tests OK)

AT+IPR=230400 also appears to crash them.

The crash/reboot appears to be a complete restart, with the module re-enumerating on the USB bus.
We are not accessing the module via USB during this test.

Not sure if this is related to the problem above, but whilst searching the forum for my issue I found this and thought it worth mentioning our experience.

Regards,
Mark Leman