BOOSTXL-CC3135: Porting the cc3135 into the STM32L4 controller

IELEKTRON TECHNOLOGIES

Part Number: BOOSTXL-CC3135
Other Parts Discussed in Thread: CC3135

As per the Programmers guide we do step by step, Now We have changed the user.h with respect to the STM32 controller and changed the OS abstraction layer to Freertos function calls. We created the project it complies well but when debugging with the hardware(STM32L496ZG) it is strucked inside the configureSimpleLinkToDefaultState( ); in main.c, By following the call graph it goes in to the vPortEnterCritical() through the #define sl_SyncObjWait(pSyncObj,Timeout) osi_SyncObjWait(pSyncObj,Timeout). For your reference we attached the main.c, user.c spi.c spi.h , osifreertos.c and osi.c and give the response as soon as possible. We also bought the interface board STM32 ADAPT board for connecting the STM32 controller to the cc31xx. We don't have stm32f4 discovery kit, we are using STM32L496 nucleo kit. We connected only the spi pins, irq pins,nHIB pins. But we are not sure whether our connection is correct, so kindly share any connection diagram to interface CC3135 with stm32l496 nucleo kit

Test.7z

over 4 years ago

0 Benjamin Moore over 4 years ago

TI__Mastermind 29085 points

Hi,

We can't share a recommended connection diagram for that kit specifically. We can help provide recommendations for debugging the interface and issues you have run into while porting the host driver though.

You are indicating that when you run your application, it gets stuck inside the "configureSimpleLinkToDefaultState()" function. This is an example function in many of our demo applications that makes multiple calls to the SimpleLink API.

Can you tell me which SimpleLink API call specifically in the configureSimpleLinkToDefaultState() function the code is hanging on?

I would expect that if there is an issue with the porting layer, the SyncObjWait calls you are referrencing could cause the system to hang on the first sl_Start(0,0,0) call.

If that is the case, I recommend making sure that the host is responding to the interrupts from the CC3135 correctly. For example, check to make sure -

1) The nHIB line is asserted when sl_Start(...) is called to enable the CC3135

2) That the IRQ line gets raised by the CC3135 some short time after it is released from hibernate AND the host responds when the IRQ line is raised

3) That the interrupt handler for the host driver is registered properly by the function attached to "sl_IfRegIntHdlr()" in user.h

4) That the interrupt handler is triggered and runs in response to the IRQ line being raised.

Best Regards,

Ben M

0 IELEKTRON TECHNOLOGIES over 4 years ago in reply to Benjamin Moore

Intellectual 380 points

Thanks for your response,

As you said, code is struck in the sl_Start(0,0,0) ,

we will do the steps you mentioned to verify the interrupt pins and get back to you.

Kindly tell us SPI and timer configuration. We will verify this in our code

0 Benjamin Moore over 4 years ago in reply to IELEKTRON TECHNOLOGIES

TI__Mastermind 29085 points

Hi,

The host SPI interface requirements are described in the datasheet on page 36 (section 5.17.6.1 Host SPI Interface Timing).

http://www.ti.com/lit/ds/symlink/cc3135.pdf

In our examples, we use the system tick for the timer. The host driver will take care of measuring the elapsed time internally. It just needs a function for reading the current timestamp. This should be connected to slcb_GetTimestamp() in the user.h file. An example implementation can be found for the CC32xx devices or the MSP432 devices in our SDK or plug-in at <SDK>/source/ti/drivers/net/wifi/porting/cc_pal.c.

Please also see this helpful thread that describes the timer mechanism and requirements for porting (both for OS object timeouts and timestamp service) -

https://e2e.ti.com/support/wireless-connectivity/wifi/f/968/t/741520

Best Regards,

Ben M

Wi-Fi

Wi-Fi forum

BOOSTXL-CC3135: Porting the cc3135 into the STM32L4 controller