I have a device and a host that use the xb3-24z8pt-j module in 802.15.4 mode and sometime the module resets to its defaults parameters. Precisely, the baud rate and the MY values reset to the defaults value. What can cause this issue? I don’t use any command that can reset the module to its default values.
You can issue the ATRE command which will reset it to defaults along with triggering the reset line or power cycling the module if you have not written the settings to flash.
I can’t issue the ATRE command because the baudrate has changed. Also, power cycling the module doesn’t help to recover the parameters. All the parameters have been resetted in the flash memory. When this happen, it’s very annoying because we heve to remove the module from the product and reprogram it.
You can force command mode by using the back door to enter command mode. That is done by holding the DI line low while power cycling the module or using the reset line to trigger a reset. This will force the module into command mode at 9600 baud.
In my case, it’s not possible to modify the baud rate to 9600 so this it not an option for me. I need to know why I ended up in this default parameter situation? Question : Is holding DI line low and trigger a reset will reset all parameters in the EEPROM?
I’m not sure I was clear. When I say to default parameters I mean factory parameter. I can change the baud rate and the MY address and perform a WR command succesfully. My parameters are valid through multiple power cycle. At some point, they are resetted to factory parameters.
I did some more investigation on my side and I realized that sometime after sending a queued CH command and a queued WR command, I don’t get a response from the module for the queued WR command. We have a timeout after 5 seconds and we resend the WR command. Could this be the problem of my issue? In the documentation, it says not to send any command before having a OK response. Is it normal if we don’t have a response after 5 seconds?
No that is not normal. You generally should get an OK after sending the command. Are you using API mode or transparent mode with AT command mode? From the sounds of it, you are not getting the OK indicating you are in command mode or you have timed out or what you think you are sending is not what you are actually sending.
I’m using API mode for AT command. The sequence of event works 99% of time but a one point it fails. I have report logs that show the problem occur always on WR command until now.
I will use a logic analyzer to see what is truly going on the serial port but I don’t see how an error on the serial port will bring the module back to its factory setting.
IF you are are using API mode and you do not get a response from a command or frame, then most likely the frame is in Error and that is why you did not get a response.
I used a logic analyser to catch the issue I have. I can see that all my communications are cleans and there’s no delay between the bytes within an AT command. My point of interest is for the WR command. 99% of time I got a response within 33ms to 65ms. But somtimes, I don’t get the OK response and at this occasion there’s a low pulse of 75us on DIN pin. I’m pretty sure this it not driven by us. So my question is what happen on pin DIN (config_n) when the module resets to its factory parameters?
As a test, I intentionnaly sent a pulse of 75us immediately after a WR command and it does nothing.
I noticed in the documentation that we must use WR command sparingly. What is the magnitude of order for the number of WR? What happend when we reached the limit?
Finally, I will ask again what can cause the module to reset to factory parameter even if I don’t send the RE command?
I can’t answer what happens when you reach the max number of write cycles. I am not aware of anyone who has. As for the other question, I have given you what info I have on it. I am only aware of a few ways to do that. One is to issue the ATRE with a WR, one is to re-write the firmware and the final is to do a four button press on the commissioning line.
I think I won’t get the answers of my questions here on this forum. I’ll try to escalate it to engineering to get the answers to my questions. Thanks mvut for your support here.
Hello, Digi has been researching this issue. To date, the ONLY way this issue has been reproduced is by causing the VCC to drop below VMin. While Digi Software Engineering is looking at ways to min-agate this within the firmware, it is imperative that your power supply design meets the modules VCC limits.