This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: Too many callbacks in SPI callback function

Part Number: CC1352R

Hello,

I set up my SPI to work in callback mode.

When the callback function is triggered after a successfull transmission an event is posted to continue with another SPI transfer. 

Lately I am having problems with software crashes. 

After long hours of debugging I seem to have found the source of the problem: 

pretty soon after my first transmissions the callback function is called from an unknown source. 

I captured the evildoer and the transaction object looks like this. No data, no bytes to send. 

I certainly do not start an empty SPI transfer to who does?
My SPI is working in 3 pin mode and I set and reset the chip select via GPIO control which worked perfectly fine so far. 

In 4 pin mode I never got any callback function calls. 

  • Hi Miriam,

    What version of the SimpleLink CC13x2/CC26x2 SDK are you using?

    Can you use a memory watchpoint to see where the write to this object is coming from?

    https://dev.ti.com/tirex/explore/content/simplelink_cc13x2_26x2_sdk_4_40_04_04/docs/proprietary-rf/proprietary-rf-users-guide/proprietary-rf-guide/debugging-index.html#memory-watchpoints 

  • Do you have more than one task? You can try to  comment out tasks one by one to see when the you don't get a false callback.

    You should also look into if all pointers are defined, the stack memories are sufficint etc to ensure that you are not accidentely access a part of the memory you didn't intend to access 

  • Hello,

    I am using SDK 4.10.00.78 and debugging with XDS100v3.

    This is how it looks when such an object arrives in the callback function: 

    I deactivated all other tasks except for a system task which I cannot deactivate. But I commented out everything it does.

    I have a query before an SPItransfer call to make sure all my pointers are defined and not empty and also that my transmission count is not zero. So I guess I am really not sending any false data on the bus. 

    as I dug deep into debugging I saw that if the controller goes lost at some point the pause button results in the program stopping at this code:

    The comment seems to describe my problem fine, but how do I disable the DMA_TX? 

    Here is a snap from the syscfg:

    I changed the values to see if it has any effect. The DMA transfer size to 0 or to 260 (which is the maximum of bytes I need to transfer). 

    Also I changed the interrupt priorities from highest to lowest. 

  • All pointers are defined as far as I can see. I have a query before I start a SPI transfer to ensure that. 

    Because you mentiones the stack size, sometimes after the task is not responding anymore I can the with the pause button that the program is at this point in the program:

    So many the stack memory size is not sufficient? I can't tell, the ROV said the stack peak for my task was below the configured 4098.

    But maybe the ISR stack is not sufficient? How can I debug this?

  • Hi Miriam,

    You can debug the system stack by looking in ROV -> HWI. 

    If there is a stack overflow, it might not always be captured by ROV. If the stack peak is close to the stack size it should be a warning, even if it does not exceed it.

  • Hello, 

    thank you all for the answers. I could not solve my problem. 
    Anyway I changed my code and moved back from using events and queues to a more low tech approach. 
    I am using now just a simple uint8_t flag in my driver which is set to a specific value when a callback from the SPI arrived. 

    My driver works fine now, however our system task which handles all our algorithms still uses events.

    I have an algorithm to handle the SPI driver which is called by events. This results in me not getting any callbacks from the SPI after a certain amount of communications! 

    It seems to me that events and SPI callbacks do not play well together for some reason. Do you have any ideas?

  • Is this SPI master? 

    Do you have a very small project that you can share that shows this issue?