CC3100: driver gets stuck in infinite loop during sl_start

Huw Percival

Prodigy 140 points

Part Number: CC3100

hi,

attempting to port to stm32f0 on a custom board, no OS. have been trying for quite some time.

when I run the spi testing project it passes fine so my SPI is working.

when sl_start is called it gets to :

retVal = _SlDrvSyncObjWaitTimeout(&g_pCB->ObjPool[ObjIdx].SyncObj,
                                              INIT_COMPLETE_TIMEOUT,
                                              SL_DRIVER_API_DEVICE_SL_START);

and gets stuck in an infinite loop at _SlNonOsSemGet() in nonos.c, in this loop the timeout counts down until it gets to 0xff and then stays there and does not stop looping.
this is the line that stops the timeout from decreasing:

#if (!defined (sl_GetTimestamp)) ||  (defined (SL_TINY_EXT))
        if (Timeout != NONOS_WAIT_FOREVER)
        {		
            Timeout--;
        }

NONOS_WAIT_FOREVER is 0xff.

I added a printf to the spi commands to see if correct looking data is being transferred (received 0's are filtered out):

Sent Data: 65
Sent Data: 87
Sent Data: 78
Sent Data: 56
Recieved Data: bc
Recieved Data: dc
Recieved Data: cd
Recieved Data: ab
Recieved Data: 8
Recieved Data: 8
Recieved Data: 11
Recieved Data: 11
Recieved Data: 11
Recieved Data: 11

so the sync patterns appear to get transferred, but nothing else happens

any help would be appreciated,

Huw

over 7 years ago

0 Huw Percival over 7 years ago

Prodigy 140 points

accidentally put the following text in the first code box instead of as a paragraph:

and gets stuck in an infinite loop at _SlNonOsSemGet() in nonos.c, in this loop the timeout counts down until it gets to 0xff and then stays there and does not stop looping.this is the line that stops the timeout from decreasing:

0 Huw Percival over 7 years ago in reply to Huw Percival

Prodigy 140 points

woops realised I had implemented SPI read and write wrong. my loop decremented len as it read, meaning the return val was 0. changed so it returned len.

still not fixed. now hard faults whilst trying to check for sync pattern

0 Benjamin Moore over 7 years ago in reply to Huw Percival

TI__Mastermind 30185 points

Hi!

I'm glad you solved the first issue. Note that the issue where the driver can get stuck when it decrements the timeout to the NONOS_WAIT_FOREVER value is known. This has been fixed in the host driver and will be released in the next CC3100 SDK. For now, you can modify the NONOS_WAIT_FOREVER value to be greater than the timeout values used. However, if you run into issues with the APIs timing out (because the decrement is too fast) you will want to implement the sl_GetTimestamp() function as part of the porting process. This will provide the host driver with an actual timer reference to use for triggering the API timeouts.

Please clarify the behavior you are seeing now that you fixed the loop issue.

Best Regards,
Ben M

0 Huw Percival over 7 years ago in reply to Benjamin Moore

Prodigy 140 points

Hi, so I found thehard fault was occuring whilst the driver was looping through the 8 byte read array in _SlDrvRxHdrRead() in driver.c

this function casts the 8-bit pointer to a 32-bit pointer to compare 4 bytes at a time.

This causes a hard fault in ARM M0 processors as it does not have the required hardware to deal with accessing data across boundaries. It has taken me quite a while to narrow down this issue but I found it explained in this forum:

www.keil.com/.../

are there any provisions in the driver to handle this problem or will I have to move to a different processor?

0 Benjamin Moore over 7 years ago in reply to Huw Percival

TI__Mastermind 30185 points

Hi Huw,

I was able to confirm that this has been fixed for the next planned release of the CC3100 host driver.

Best Regards,
Ben M

Wi-Fi

Wi-Fi forum

CC3100: driver gets stuck in infinite loop during sl_start