Hi,
we have a problem with listener DWM1001.
When the listener do a resync task the serial port (usb) stops receiving commands.
You can reproduce a resync task manually through android app for example by enabling or disabling the LED of “the initiator” unit.
When resync task occurs often serial communication hang also the output of the lep command hang too then the serial is unresponsive, the only way to resume operation is to turn off the power for a few seconds to the listener unit.
We have tried with firmware version R1 and R2 the problem is the same.
Is it a known problem? There is a solution?
Thank
Regards.
The Module software may be going back to Generic mode.
Have you tried hitting ‘enter’ twice on the keyboard?
Hello massimo,
To enter serial mode you need to press two enters then only you can fire lep command.
The issue of serial port being non responsive might have something to do with the USB serial library that you might have used. Yes serial port stops sending value when the tag looses line of sight and continues once its back in line of sight. Accurate value of x,y and z might also sometimes stop the tag location update.
Hope this helped.
I tried, the serial does not accept any input command after the the resync task even the enter command “@”.
I tried on about ten DWM1001, the problem is the same.
Hi Massimo,
does it mean the module some hangs and sometime not?
If it hangs, does it reset automatically after 10+ seconds?
Can you observe some strange blinking of the LEDs when it happens?
Cheers,
TDK
Hi,
yes, the listener performs a resync operation realigning itself correctly, after this task serial communication problems are encountered, the input mode of serial hang every times, sometimes hang the output mode too.
Hi Massimo,
that’s strange. How the module is powered? To which device is the module attached to in order to get the serial communication?
Cheers,
TDK
The initiator and all anchors are powered with power supply, the listener is connected to a USB port PC with Windows 10 OS.
For now I’m solving through this workaround: in order to guarantee the continuity of the service, I have installed 2 listeners for each zone and every 30 minutes I restart the initiators using J-Link Commander, I discovered that the communication channel used by J-Link is working, this allows me to reboot teh DMW even when the channel is blocked via serial port (putty).
Restarting the PC does not remove the voltage from the DWM1001 (usb port) the usb voltage is not interrupted during the restart then after rebooting DWM is still in hang state. The only way I have found for now is through JLINK.
Greetings, Massimo.
Hi Massimo,
thanks for sharing the work-around. I don’t know why that happens in your system.
We have not experienced a such issue. Please keep us posted if you found out the reason.
Thanks,
TDK
I think the problem is related to the application firmware layer because the serial port still communicates towards the lowest level application layer even when the application firmware does not accept and does not send communications, instead the communication with the lower layer is always stable and responsive . I tried with 2 sets of DWM1001 (24 anchors), these as listener and as initiator, the problem does not change. I assume that I am working with some buggy DWM sets.
Hi Massimo,
can you please confirm that I understand correctly your following observations?
-
You use les/lep command to get data out from the Listener via Shell interface. After the “resync” the UART hangs and you can no longer communicate via Shell.
-
The issue can be solved by reseting the DWM1001 using J-Link SWD. After the reset the Shell is available again.
-
When you mentioned about “the serial port still communicates towards the lowest level application layer even when the application firmware does not accept and does not send communications, instead the communication with the lower layer is always stable and responsive”: what do you mean with lowest and lower layers here?
What we have observed is after sometime or some unspecific event the Segger can block the UART. Only a re-power would recover the issue. We have observed this on many DWM1001+DEV boards. The same firmware does not happen with other SWD programmer so we do suspect some issue in the Segger firmware. We don’t have an explanation yet for this issue.
But it looks like your issue might be something else because a reset would recover the UART. If you have a chance please try this test: power the DWM1001-DEV with a battery and via USB as normal. Then re-plug the USB cable when the issue happen. Would the issue remain or the shell would be available without the need to double enter?
Thanks,
Cheers, TDK
Hi TDK
The point one and two are correct.
I would like to clarify the third point.
I use segger only to reset the DWM listener (only the listener type) when it is no longer reachable through the Decawave software, via serial (putty) it does not respond, When the DWM listener is in a non-responsive state, it can be reached only via Segger through Jlink. With this software I send the reset and in this way I make the Decawave software of the listener work again until a new resync
I will also try to power the listener with the battery.
The antennas (active antennas) are connected to power supplies as they are positioned at a height of 5 meters and, fortunately, these never give any problem, it would be a problem to reset them each time at that altitude
The problem is only on listeners (passive antennas), each of these DWMs are connected to a dedicated computer, and the coordinates (lep) are sent with a request to the decawave software through java.
When a resync is injured java goes wrong, the error comes from the fact that the DWM communication is interrupted with the serial port, or better, through the serial port there is no communication towards the Decawave software layer, instead via Segger the commands to the chip continues to work, with these commands (JLink) I perform a reset (h, r, g) of the DWMs, simulating a momentary interruption of voltage at the chip (in the same way as re-plug the USB), this restarts the software and everything starts working again.
The same thing happens without using java, with a resync request, the coordinates of the lep command are blocked and often they don’t start working again.
I hope I have clarified what happens. Thanks a lot.
Best regards
1 Like
Hi Massimo,
many thanks for the details. Can you please clarify what do you mean with “with these commands (JLink) I perform a reset (h, r, g) of the DWMs, simulating a momentary interruption of voltage at the chip (in the same way as re-plug the USB)”? What are the “h, r, g”? Is it some Segger commands? When you do this, can you see in the system log (e.g. dmesg) that the USB has been re-enumerated for the DWM1001-DEV board?
Thanks,
Cheers, TDK
Hi TDK,
I scheduled this batch command
“JLink.exe -device NRF52832_XXAA -if SWD -speed 1000 -CommanderScript C:\Gateway\Scripts\ResetHW.jlin”,
my ResetHW.jlin is a txt file like this
“h,r,g,exit”,
it sends these sequence, “halt”, “reset”, “start”.
In this way DWM hardware performs a reset, through JLink.exe the reset is performed by the chip itself, skipping the DW layer as it is not responsive.
I perform this task every 30 min, it takes about 2 seconds.
I have no messages in the event viewer that relate to usb controller activity, or status changes. The operating system is windows10, I will check if it is possible to activate some debug logs on the usb controller.
Massimo