• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 51 subscribers
  • Views 1547 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.

CC1350 stuck in ICall_taskEntry

pixbroker
Genius 5820 points
Other Parts Discussed in Thread: CC1350

I am working on a custom board project that uses the SensorTag project as a starting point. Over the past few weeks i have been working on the various drivers needed for the sensors on this board. It's been going well, largely due to the help from this forum. Thanks!

While working on the drivers, i had disabled all the BLE related calls in main.c, so i could just focus n my custom tasks and drivers. Now i would like to work on the BLE part of this project and re-enabled the BLE calls in main.c and am running into a problem when none of my tasks run anymore. 

I have narrowed it down to this call:

ICall_createRemoteTasks();

If i make this call, and stop after a while of execution, the stack list looks like this:

I tried to step thru the ICall_taskEntry function but didn't notice anything strange. All my custom tasks are created, but their taskFxn never runs. 

If i pause execution, and single step, it seems the processor is looping these 3 instructions forever:

So, clearly, i broke something at some point during my driver work. But i am not sure what that would be. I am assuming something related to the stack? I made no changes to the stack, but i downloaded it a few times just to make sure, no change.

I know this is not much info, but does anyone have some idea how to track down this problem?

  • 0
    TI__Guru** 105180 points
    Hello,

    Based on the Task ROV output, the code is likely in the Stack task context. Hard to tell what is going on since I don't know where the code is linked to. I would try starting with a clean SDK install, then incrementally add your changes to see where it breaks.

    Best wishes
  • 0 in reply to JXS
    Genius 5820 points
    It isolated the issue with a fresh BLE Stack 2.1 install to the fact that i can't get the SensorTag project ported properly to CC1350. Here are the steps i did:

    * use a fresh copy of SimpleBLEPeripheral for CC1350, everything works ok.
    * added my drivers and customizations back into this project, everything still works as expected, including BLE


    * use a fresh copy of SensorTag, change include paths and defines to match those of SimpleBLEPeripheral for CC1350 (i.e. CC26XXWARE -> CC1350WARE, etc). project builds and runs fine as long as i comment out calls that start ICall in main.c
    * as soon as i start ICall, things behave line described in my original post.

    So it seems there is something i am missing in adopting the project settings changes for CC1350. One thing i noticed is that the ICALL address pointer (boundary tool config) is different between the SensorTag and the SimpleBLEPeripheral for CC1350. Could that be it? How to change it?

    It would be of great help if someone could slip me a copy of the CC1350 SensorTag project. I know it exists :) (hint, hint)
  • 0 in reply to pixbroker
    TI__Guru** 105180 points
    Hello,

    The ICALL_STACK0_ADDR will change based on the size of the configured BLE Stack. In the default STK projects, GAP Bond Manager & SNV are disabled, so the stack image is smaller compared to SBP.

    Are you using the same STACK0 & RAM0 address values in both App & Stack projects? Refer to the Boundary Tool section in the BLE SW Dev Guide (SWRU393). If these values are not aligned in the linker & compiler, you will see incorrect behavior.

    Best wishes
  • 0 in reply to JXS
    Genius 5820 points

    So i have decided to continue with the SPimpleBLEPeripheral example project for CC1350 as i just can't seem to get the SensorTag project working on the CC1350. 

    But now i am running into problem related to SPI. I have custom drivers that talk to some SPI parts just fine within the SensorTag project, but that same code doesn't seem to work within the SimpleBLEPeripheral project. Things get stuck on driverlib/setup.c

    i defined TI_DRIVERS_SPI_INCLUDED which is what seems to be the case in the SensorTag. I noticed that by default the SimpleBLEPeripheral was using SPI DMA, but changing the define and including the non-DMA SPI driver and bsp_SPI.c should work, but it doesn't. 

    what other details should one keep in mind when comparing SPI project configuration between SensorTag and SimpleBLEPeripheral?

    Thanks.

  • 0 in reply to pixbroker
    TI__Guru** 105180 points
    I'm not sure why you see this behavior. Since you have a working setup, SPI wise, on the SensorTag project, I would suggest using the debugger to step through the SPI driver init code to see what is getting executed in a good case vs. the non working case. Both SBP & STK projects use the same TI-RTOS & CC26XXWARE driverLib (provided the path variables are the same), so it's likely just a config issue.

    Best wishes
  • 0 in reply to JXS
    Genius 5820 points
    I tried stepping through the SPI routines in the SBP case and it seems it's resetting the chip some time during read, but I'm not 100% sure on that. One thing i noticed is that SBP is configured with SPI DMA drivers and STK is SPI without DMA. Also, by default, the SPI files are excluded from the SBP build. So I'm not sure if SPI ever worked correctly in SBP CC1350 project.

    Can someone familiar with the matter, explain the steps involved in setting up SPI drivers with and without DMA from scratch? This would help to understand all the moving parts involved and allow me to check and compare the projects more carefully.

    Thank you.