• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 40 subscribers
  • Views 889 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3100 interrupt during sl_recv (dummy packets)

Tiago Marques62
Prodigy 50 points
Other Parts Discussed in Thread: CC3100

Hi.

I have a problem in sl_recv function. I'm using the CC3100 in a particular platform, in a multi-threaded environment and over the NutOS. When I call sl_recv to get a certain amount of packets (for example, 100 packets of 532 bytes), randomly, the chip stops receiving. 

I think this happen because occasionally there's an interrupt during physical reception. I'm using SPI. My receive function always returns right and in this situation returns 0 (0 bytes read).

This interrupts are always in consequence of dummy packets (0x0063). 

I saw, in other related posts, that there's only two situations in which chip sends dummy packets (flow control or wrong IRQ). The first is impossible, because my application call sl_send and sl_recv, interchangeably, i.e., the application echoes the receiving data. 

In this example (100 packts of 532 bytes) CC3100 sends, on average, 7 or 8 dummy packets. After that when I try to communicate with chip again, it stops in _SlDrvRxHdrRead because it doesn't receive the sync pattern never more.

 

Someone could help me? 

 

 

Thanks. 

  • 0
    TI__Mastermind 27390 points
    Hi Tiago,

    I suspect the issue is due to something wrong with the OS porting. Have you tried the same program using Free RTOS or TI-RTOS?

    -Aaron
  • 0 in reply to made4engineering
    Prodigy 50 points

    Hi Aaron.

    I didn´t try with another OS. Recently, I was watching at the mqtt client example of SDK, in particular, the OS functions, like osi_spawn, vSimpleLinkSpawnTask, and so on.

    Although slightly different, I'm using the same concept. Please, correct me if I'm wrong:

    LockObj -> I use mutex;

    SyncObj -> I use semaphore;

    osi_spawn -> I call my spawn function from interrupt routine (_SlDrvRxIrqHandler), like the driver does;

    vSimpleLinkSpawnTask -> I call my spawnEntry function from a dedicated thread initiated before calling any API (including sl_start).

     

    I think my problem is related with timings. I say this because I can't understand why CC3100 generates so many dummy packets during communication.

    I checked my SPI channel and it's ok. I tried with another device on the same SPI bus and it works well.

    I also checked that if I reduce the SPI speed from 20 MHz to 1 or 2 Mhz, CC3100 works slightly better but not 100%.

    In _SlInternalSpawnTaskEntry and _SlInternalSpawnEntry_t functions, the driver uses LockObj (mutex in my case). Are they extremely needed? NutOS does not allow to use mutex whitin interrupt routines. I doubt the problem is related whit it, because my thread that calls _SlInternalSpawnEntry_t has highest priority. 

    Any ideia?

    Thanks for your answer.

    Tiago Marques

  • 0 in reply to made4engineering
    Prodigy 50 points

    Hi Aaron.

    Any help can be helpful.

    What is the meaning of the dummy package? CC3100 sends this packet in which situations?

    Best regards,

    Tiago Marques

  • 0 in reply to Tiago Marques62
    TI__Mastermind 27390 points
    Hi Tiago,

    I'm not sure what you mean by dummy package. As far as the lock objects in the Simplelink driver, you cannot remove them and expect the driver to function correctly

    -Aaron
  • 0 in reply to made4engineering
    Prodigy 50 points

    Hi Aaron.

    I suppose that a dummy packet a packet with opcode 0x0063 (SL_OPCODE_DEVICE_DEVICEASYNCDUMMY), as described in documentation.

    After carefully analyzing the code, I realized those lock objects do nothing due to the different priorities of the threads. However, I block these objects otherwise.

    The problem is when chip send the dummy packets. When it doesn't send, the behavior is normal.

    Tiago Marques