I am using 4 DWM1001 connected through the same SPI buffer to an STM32F4. The SPI speed is 7.5Mbs.
The Tags configuration is :
CFG : UWM operation mode ACTIVE
Loc engine enabled
INT_CFG : loc-ready
Spi_data_ready
The plan is to get position from all DWMs every 100ms via SPI then send them via UART.
For communication method, I pool the state of the data_ready_pin when I am expecting informations using a predefined “number of attempts” value as a threshold.
Everything is working good and I get data perfectly. But after hours (sometimes minutes), one ore more DWMs returns ZERO values in all of X, Y, Z and PQF.
Sometimes the modules get back to work after few seconds, and sometimes they simply loose their configuration.
I reconfigure the PANID, CFG and INT_CFG registers in the DWM’s initialization procedure. Then resetting and putting them in IDLE state.
After these steps, the periodically position reading can begin.
This makes me able to get position periodically from the modules for maximum few hours. Then, if the problem occurs again, I just reset the STM32 then continue my tests.
But I need to solve this problem.
I’ll be grateful if anyone helps me understanding what is exactly going on.
Hi @Mouadh
if I understand it correctly then you have one STM32 connected to four DWM1001 with shared SPI line (CLK, MISO, MOSI) and for each DWM1001 you have two ( CS and IRQ) lines connected from DWM1001 to STM32? If so, could repeat the issue with only one active DWM1001 and leave the rest DWM1001 unpowered / disconnected?
You are mentioning the configuration loss - is this loss permanent or it gets recovered when you reboot the module?
Yes that’s true, I was able to reproduce the error with one DWM.
Sometimes, the DWMs don’t loose their configurations but stop sendig position values causing HAL_SPI_ERROR or HAL_SPI_TIMEOUT. A hardware reset solve this.
Sometimes the DWMs looses their configurations for good and I have to reconfigure them again before I’ll be able to use.
I tried to force them switching to IDLE state when this happens but it doesn’t work.
Hi @Mouadh
so far we have never observed such issue before and the system was released long time ago. The RPi gateway is connected via SPI so it is reliable connection and well tested for a days. I cant say that there is not some software bug that it will cause such issue but it is unlikely.
Just double checking with polling data_ready_pin you mean that you are checking reading the status of IRQ pin and you are not reading the IRQ register status. There is an known issue that can cause a UART hang-up while you will poll the register status. But you operate via SPI and you are polling the status pin.
Very weird is that you are mentioning configuration loss, I have never head about it. Internally there are two environment area one is active and the second one is backup which contains previous configuration. Could you do a test when you will set the system to some update rate (10Hz for example) and then to another update (1Hz for example) and observe if the DWM1001 runs in the first configuration while the configuration gets lost? The configuration area can not get changed by itself and it has to be triggered externally (SPI, UART, BT, UWB).
The SPI communication loss and configuration loss are very suspicions. Are you 100% sure that you not sending there accidentally some else command.
Could you describe us you device a bit and where it is used?
Yes I am 100% sure that we don’t send any other command except Get Position’s one.
We are using DWMs in our drone to perform an autonomous landing to a 3-axis moving base.
I did the 1Hz update rate test and the results are better then the 10Hz ones.
Test duration: 2h
Observation: None of the modules had lost its configurations.
When it comes to the tests with 10Hz update rate, DWMs looses often their configurations after hours, It had been replaced each time with some default configuration.
Any chance you are getting a power brownout condition? A brief dip in the power supply that is causing the module to reset unexpectedly?
For that matter how is the reset line being driven / pulled up? If it is on a very weak pull up could it be picking up noise that is causing an occasional reset? I know this is a long shot but if you are on a drone you’re going to potentially be getting a fair amount of electrical noise from motors etc… depending on how well isolated different systems are.
Hi @Mouadh
as @AndyA mentioned I would expect some power issues or something else related to the power/ IO lines. The module hang-up could be caused by power outage / extra noise in reset pin or something else that can cause some GPIO hang-up in some strange state. I have seen similar behavior with different MCUs in mobile robots. To be more specific: we get antistatic dischargers between robot wheels and PCB - it was fixed by improving PCB layout & adding some extra shielding.
The most unexpected stuff is the configuration loss because the configuration is guarded by CRC in the environment - this is 100% well working. Each time you change the configuration it calculates new CRC and save the environment into the FLASH + stores its CRC. After reboot it loads the environment and check the CRC and this is not working for you. Again I would expect that there is some extra noise in power lines to this didnt work well at chip level.