Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

µSD-logging fails in combination with other SPI decks like loco-deck and flow-deck #270

Open
Woody7777 opened this issue Dec 1, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@Woody7777
Copy link

commented Dec 1, 2017

Using both the µSD-card deck and the loco deck, logging will work only a short time (a few 100 log entries) before it stops. Interestingly, this behaviour seems not to depend on variables logged, sampling rate or buffer used for µSD-config file but solely on time after startup, e.g. with 1000 Hz you'll get ~150 log entries while with 10 Hz you'll get only 20 or so (not exactly reproducible to my experience).

I used the latest firmware and VM2017.03 to reproduce this behaviour. Unfortunately, I don't have a debugger at hand currently. Maybe someone can have a look at the debug prints?

@tobbeanton

This comment has been minimized.

Copy link
Member

commented Dec 21, 2017

I've started to investigate this and my first impression is that the usdWriteTask doesn't get time to run. Will investigate further why and if so really is the case.

@ataffanel ataffanel changed the title µSD-logging fails in combination with loco-deck µSD-logging fails in combination with other SPI decks like loco-deck and flow-deck Feb 5, 2018

@ataffanel

This comment has been minimized.

Copy link
Member

commented Feb 5, 2018

The problem has also been observed with the flow deck: https://forum.bitcraze.io/viewtopic.php?f=2&t=2821

@simplexsigil

This comment has been minimized.

Copy link

commented Feb 8, 2018

I played around with changing the task priorities of the USDLOG_TASK_PRI and USDWRITE_TASK_PRI as well as the priority of the "pamotion" task of the flow deck (it was hard coded to 3).

However, apart from not getting enough runtime, there also appears to be a mutex hold problem.

For the values
USDWRITE_TASK_PRI = 2
"pamotion"-Task-Priority = 1
USDLOG_TASK_PRI = 0

The following error occurs:
SYS: The system resumed after watchdog timeout [WARNING]
SYS: Assert failed at src/lib/FreeRTOS/tasks.c:3495

With these settings this always happens, with the standard settings it only happens sometimes.

@Woody7777

This comment has been minimized.

Copy link
Author

commented Mar 19, 2018

I made an interesting discovery when playing around with the baudrate for SPI communication:
As long as it is set to the default (2MBit), the error described in the post before occurs.
However, changing it to something higher, the error disappears but logging still seizes after a couple of log entries - as well when using higher priorities. Still, I was asking myself why we're using the lowest baudrate available?

Unfortunately, a watchdog timeout sometimes occurs when starting up using these settings (with no logged assert). I only have one crazyflie for testing, so I can't verify the behaviour.

Well, priorities and baudrate are just the most obvious settings that I think may lead to this issue.
I'm sure there are people out there knowing more details regarding this module.
I know it's not easy to instruct someone on issues like that, but I'd be really happy to help... on my own, I'm missing clues where to have a look next :-(

@tobbeanton

This comment has been minimized.

Copy link
Member

commented Mar 20, 2018

I quickly looked at this too and I could not find an easy solution, but I got a bit wiser. Getting fast enough bus access is one of the reasons. The flow deck runs on max 2MHz clock and the loco deck does a lot of small accesses. Either of these is giving the sd-card problems. Why it just stops logging I don't know though, that feels like a bug.

Optimizing the SPI access could be one way forward and e.g. only switch SPI speed of needed. Another thing would be to look at the mutex protection of the SPI driver. Maybe it doesn't work as it is supposed to.

@shushuai3

This comment has been minimized.

Copy link

commented Aug 9, 2018

In order to use both flow and SD decks, I change the SD port from spi1 to spi3. After changing the related driver as well as DMA stream, it can log for any long time while flow deck is working.

However, this is not the direct way to solve the bug. Look forward to seeing the smart solution.

@tungnx94

This comment has been minimized.

Copy link

commented Aug 15, 2018

@shushuai3 can you share your changes (i.e which line of code was modified) to make this work ? For our research experiment this is very important. Thanks in advance :).

@shushuai3

This comment has been minimized.

Copy link

commented Aug 15, 2018

@tungnx94 You can find the code on branch ''sdspi'' in https://github.com/shushuai3/crazyflie-firmware.git
Remember to change the sd card connection as CS->PA3, SCLK->PC10, MISO->PC11, MOSI->PC12, while keeping the VCC, GND, and OW. Good luck.

@tungnx94

This comment has been minimized.

Copy link

commented Aug 16, 2018

@shushuai3 I pulled your code just now. Can I use it rightaway or I need to modify anything ?

@ataffanel

This comment has been minimized.

Copy link
Member

commented Aug 22, 2018

@tungnx94 this requires to quite heavily patch the sd-card deck, nothing impossible but you need a good soldering iron and good soldering skills

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.