You have some tricky problem there. Basically what you are seeing should not happen as the transfer function uartslkSendDataDmaBlocking is guarded by a uartBusy semaphore so the DMA should always be free before it is setup. I think the while loop is only there for precaution.
I tried to replicate your problem with the latest official FW but was unable to. What FW are you running?
The new optimized syslink should not effect the sending of data, only receiving but could we worth testing.
Crazyflie restarts in air using experimental firmware
-
meyigo2018
- Beginner
- Posts: 10
- Joined: Wed Jun 14, 2017 1:43 pm
Re: Crazyflie restarts in air using experimental firmware
Hi Tobias,
I apologize for the late reply. I just had a chance to thoroughly test the code.
Firmware:
We are using customized firmware where we replace the crtp_localization_service.c with crtp_broadcast_service.c to receive and route packets from boradcast address. You can find code here, https://github.com/philip-huang/crazyfl ... _service.c if you'd like to skim through it. We are tying to borrow the broadcasting ideas from crazyswarm by USC.
Observations:
What I found is that with one crazyflie, the problem occurs if you wait long enough (> 30 min) or you keep connecting and disconnecting for several times in a roll without forcing it to restart. There could be two kind of results. One is that it got stuck at the while loop in uartslkSendDataDmaBlocking the other is that it goes to sleep mode at https://github.com/bitcraze/crazyflie-f ... tem.c#L266.
For the first case, I can see the DMA transfer is still enabled since the least significant bit of DMA7_STREAM5->CR is 1. However, at the same time, NDTR = 0 which means there nothing left in DMA's data buffer. Shouldn't the Transfer Complete Flag will force an interrupt to clean up DMA (disable DMA stream)?
For the second case, I found that crazyflie is mostly in IDLE mode. In debug mode, when I stopped the CPU to see where it is in the firmware, I never stopped in the syslink tasks. I'm wondering if the task is somehow gone. Another thing that supports my suspect is that LED on M4 is off, which means it's not transmitting nor receiving.
I'm sorry about asking such an involved question. I would appreciate any suggestions you have.
I apologize for the late reply. I just had a chance to thoroughly test the code.
Firmware:
We are using customized firmware where we replace the crtp_localization_service.c with crtp_broadcast_service.c to receive and route packets from boradcast address. You can find code here, https://github.com/philip-huang/crazyfl ... _service.c if you'd like to skim through it. We are tying to borrow the broadcasting ideas from crazyswarm by USC.
Observations:
What I found is that with one crazyflie, the problem occurs if you wait long enough (> 30 min) or you keep connecting and disconnecting for several times in a roll without forcing it to restart. There could be two kind of results. One is that it got stuck at the while loop in uartslkSendDataDmaBlocking the other is that it goes to sleep mode at https://github.com/bitcraze/crazyflie-f ... tem.c#L266.
For the first case, I can see the DMA transfer is still enabled since the least significant bit of DMA7_STREAM5->CR is 1. However, at the same time, NDTR = 0 which means there nothing left in DMA's data buffer. Shouldn't the Transfer Complete Flag will force an interrupt to clean up DMA (disable DMA stream)?
For the second case, I found that crazyflie is mostly in IDLE mode. In debug mode, when I stopped the CPU to see where it is in the firmware, I never stopped in the syslink tasks. I'm wondering if the task is somehow gone. Another thing that supports my suspect is that LED on M4 is off, which means it's not transmitting nor receiving.
I'm sorry about asking such an involved question. I would appreciate any suggestions you have.