SPI + print causes board resets

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
cohuc_3807591
Level 3
Level 3
5 likes given First like given

Hello All:

Im having a really frustrating issue on the CYW43907 - our code is reading a few values over the SPI bus and then printing them, but the combination of the SPI transfers and the printing is causing the board to reset itself and the SPI transfers to bug out. IF we remove the SPI transfers, the printing works just fine, printing out the pre-initialized values. If we remove the print, we see the SPI transactions working out from the logic analyser. Interestingly, the only prints that are failing are the ones where we are printing variables - ie the just printing a static string works just fine.

Other useful information:

1. Our code isnt using any RTOS, no network needed so just calling wiced_core_init()

2. We are using the SPI bitbang driver at 1 Mhz (base frequency)

3. We are toggling some GPIO's around the SPI transfer - the SPI part needs toggle pulses on each end of the transaction

4. We've tried using both WPRINT_APP_INFO as well as plain old printf

Any ideas would be invaluable, this is a critically needed fix for our project. Thanks!

0 Likes
1 Solution
DaMo_2831246
Level 3
Level 3
First like received First like given

Any chance you're blowing your stack?

The formatting portion of the printf() library call requires a large amount of stack space -- at least 6KB of stack to be able to successfully format the string. The behavior you're describing is very consistent with what we see when we're trying to use printf() from a thread with a smaller stack.

WPRINT_APP_INFO macro just uses printf() under the sheets, in any case.

Good luck!

View solution in original post

4 Replies
DaMo_2831246
Level 3
Level 3
First like received First like given

Any chance you're blowing your stack?

The formatting portion of the printf() library call requires a large amount of stack space -- at least 6KB of stack to be able to successfully format the string. The behavior you're describing is very consistent with what we see when we're trying to use printf() from a thread with a smaller stack.

WPRINT_APP_INFO macro just uses printf() under the sheets, in any case.

Good luck!

Just saw that you're running RTOS-less; not sure how much stack gets allocated in that case, but I'd still check into that as the system will definitely still allocate some RAM to stack, some to heap, some to global variables, etc.

Agree, looks like a stack allocation issue.

cohuc_3807591
Level 3
Level 3
5 likes given First like given

Hey dave_2831246​, ZhengbaoZ_96​:

Thanks to you both for the advice - I had never encountered an actual stack overflow before and thus I wasn't familiar with the symptoms. I don have a follow up question though:

So I was able to get it working, but only by making the function run in its own dedicated thread (with sufficient stack size). I tried many times, with many different but sufficiently large stack sizes on the main thread by editing WICED_DEFAULT_APPLICATION_STACK_SIZE in wiced_defaults.h, but those changes never seemed to take effect. I tried all the edits using wiced_core_init() as well as when using ThreadX via wiced_init() as usual (ran make clean between runs to be extra sure changes were being applied). Any ideas on what gives? Could this be a bug or am I missing something? Thanks!

0 Likes