- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
10-05-2017 08:56 AM
I'm using the gecko SPI library to connect to a TI SimpleLink CC3100 device. I'm able to bring up the device numerous times, but without fail, it will lock up on the fifth initialization. I connected to our board using a debugger and was able to get the stack trace for when it locks up. It appears the SPI driver is hitting a hard loop waiting for a SPI write to complete.
Using a logic analyzer, as far as I can tell, things should have kept working like the first four bring-ups. I see the same traffic come out of the master MCU to the CC3100 and the same response values (all zeros) from the CC3100. I can't see anything outside of the SPI driver itself that would be causing this.
The stack trace is in the attach image, but this is the particular line it's stuck on:
while ( handle->blockingCompleted == false );
We are building the BGAPI files from source every time. Unfortunately I inherited this project and wasn't the one who initially set everything up, so I don't know for sure where the BGAPI files came from. But the version at the top of .../_bgapi/spidrv.c says the version is 5.1.3.
As far as I have been able to tell, we are using the "LDMA". Our MCU is an EFR32BG1B232F256GM48.
Has anyone encountered this before? Is there anything that I should verify is happening on bring-down? Let me know if there's any other info I can provide!
Solved! Go to Solution.
10-09-2017 11:16 AM
The latest version of spidrv is 5.2.2. So my first suggestion would be to update your spidrv to the latest version and see if that fixes the issue. If it does not, there are a couple of things to try -
1. reduce the SPI clock and see if the lockup still occurs the fifth time
2. If 1 is successful, the next step would be to make sure that the RX FIFO is being cleared
10-09-2017 11:24 AM
Sorry, I forgot to update this last Friday. We were able to figure out the issue, and it was that we were doing:
We ended up allocating more DMA channels until they just ran out. So a pretty simple user error.
Thanks for the suggestions, though!