• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 52 subscribers
  • Views 496 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RTOS/LAUNCHXL-CC2640R2: Adding Second Thread to OAD Off-Chip Example

dogus yuksel
Expert 1030 points

Part Number: LAUNCHXL-CC2640R2

Tool/software: TI-RTOS

Hi,

My basic problem is that: I cannot add a second thread to the code under the SDK 3.10.0.15/blestack/OAD_OffChip example to use my I2C sensors.

I have a cc2640R2 launch board and I wrote code by your example under the SDK 2.40.0.32/blestack/simple_pheripheral. I added a second thread to that code by using this link: http://dev.ti.com/tirex/content/simplelink_academy_cc2640r2sdk_2_30_02_00/modules/blestack/ble_posix/ble_01_posix.html and it works just as I want without any problem. 

Then, I needed to add OAD property to my firmware and (by the way, I upgrade my SDK to 3.10.0.15) I ported my code under the SDK 3.10.0.15/blestack/OAD_Off_Chip example and it does not work. In my application, I started the second thread via BLE by using a mobile app. With the mobile app, I can do whatever I want with characteristics, sending and getting data, etc but when I start the thread, my BLE connection is broken. In the meantime, I am sure that, I can start the thread and my thread runs without any problem. I checked it by debugging. 

Then, I thought that maybe I did some mistakes while code porting because my code is not small. To test it, I just directly import the OAD_Off_Chip example to my CCS and I directly add a second empty thread just like the link above said (I added thread calling function in "main.c") and I observed the same problem, thread runs without any problem (I can see it in debug again) but BLE corrupts. I cannot see my device in the mobile app's scan result page (I think; because, in this condition, I immediately start the thread just after starting BLE stack in main.c).

My CCS ver:  8.3.0.00009

Could you please help me with this issue.

Thanks,

Doıgus

  • 0
    TI__Guru 57865 points

    Hi,

    Assigning this to one of the experts.

  • 0
    TI__Intellectual 2430 points

    Hi Dogus,

    I fear that the connection events might be getting missed.

    Do you know if your BLE thread is still running? Could it have crashed due to some conflicting setting? Do you have any way of debugging the BLE thread?

    The first thing I would recommend is to understand why the connection was lost.

    Do you have a sniffer log? BTool log?

    Best Regards,
    Yuval

  • 0 in reply to Yuval G
    Expert 1030 points

    Hi,

    Thank you for your reply.

    I cannot be sure what is wrong and how can I debug it.

    I might be corrupted the stack app while trying to debug the program via CCS in my previous attempting because I faced a different problem now.

    I recompile whole programs after any changes in my (only) user app and then upload to the card. I compile and upload programs in this order: stack app, user app, and bim app. In my previous attempting, I directly pressed the debug button. Now, it seems working normally. I toggle one led in my second thread and toggle another led via BLE commands at the same time. It means that it works I think.

    So, is my way right? I mean, I have to recompile whole programs in a specified order and upload them also in the specified order. If not, is it normal to see the problems that I mentioned in my previous questions?

    Also, there is another thing that I can see debug prints via serial terminal just like below (original  code's debug prints);

    SBP Off-chip OAD v0001

   >
BD Addr: 0x546C0EA04925
Connected to: 0x4C3488177FF4

GAPRole Initialized
Char 1: 48

    But if the second thread was started, serial debug prints cannot be seen on the terminal anymore but the card works because my whole leds work normally (one of them toggle in second thread forever, the others can be toggled via BLE command).


    Thanks,

    Dogus

  • 0 in reply to dogus yuksel
    Expert 1030 points

    Hi,

    Actually, this is not a very problematic thing for my application for now but this situation is normal or I missed something?

    Thanks,

    Dogus.

  • 0 in reply to dogus yuksel
    TI__Intellectual 2430 points

    Hi Dogus,

    For your first question, yes, it is important that you compile and flash the different images in the correct order (there are build dependencies between the them).

    To answer your second question, if the UART driver is opened through a certain thread then the shared resource is being hogged by the thread that opened it.

    You could find a way to include the Display_Handle received by Display_open() in both threads and then send prints through both threads.

    This can be done by either:

    a) Opening the driver through a shared main file and then sending the handle down to each individual thread

    b) By opening the dirver in one thread and using an extern declaration on the other thread file to use the same handle.

    c) Alternatively, you could also close and open the driver every time you switch between the threads (I'm not 100% sure how this would be done but this should be possible).

    Best Regards,
    Yuval

  • 0 in reply to Yuval G
    Expert 1030 points

    Thank you so much.