• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Subscribers 16 subscribers
  • Views 390 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.

LP-CC2652RB: SimpleLink 4.40.04.04 - SPI + JSON and Thread can't get up

Sascha Ehlers1
Intellectual 435 points
Part Number: LP-CC2652RB

Having a weird problem, seems like it is in SimpleLink 4.3.00.54, too.

Project started with empty_ftd:

- enabled SPI using DIO25, DIO27 and DIO26

- enabled JSON

Created one task only for the SPI stuff..

So now, OT can't get up.. OtStack_setupInterfaceAndNetwork (called from empty_task) never returns.. SPI task is running fine..

Only thing to get it working again is to remove the SPI or the JSON parts.. (So that they are not getting compiled)

Even letting it enabled but removing the code works.

Removing is not necessary, just getting sure that it's not getting compiled and will be optimized out even does the trick too!

Have no clue what this is.. Maybe RAM/Flash limits reached? Some of the OT flash settings stuff is getting corrupted?

Any idea? Is this a known problem?

Thanks

  • 0
    TI__Mastermind 28010 points

    Hi,

    Can you elaborate what is the JSON you are talking about?

    I have not run into this issue before.
    Please check of your scenario is correct :

    You have setup a separate task to handle SPI activities.
    When this SPI task is present (started in your code), the empty example does not work (seems that only this SPI task is running).
    When this SPI task is absent (either not started or not compiled in), the example works as expected.

    Can you provide an overview of what the SPI task does?
        What priority is it setup with (pthread_attr_setschedparam) ?
        What stack size is it setup with (pthread_attr_setstack) ?

    To check more info on the tasks, have you tried using the ROV in CCS ?
        Tools --> Runtime Object View

    Other than adding the SPI, anything else you have added in the syscfg file ?

    Appreciate your time answering these questions -- hopefully it will help us to fix the issue.

    Regards,
    Toby

  • 0 in reply to Toby Pan
    Intellectual 435 points

    With JSON, I mean your provided JSON parser and builder library.. And totally forgot to tell that I am using COAP as well..

    SPI task just updates an APA102 LED in a specific interval and otherwise sleeps.

    SPI task has 2048 stack.. question: what is the min. stack size? had used 1024 but those task randomly stopped working sometimes..

    SPI task has a priority of 3.

    ROV.. Never used before.. But, in my error-case I cant see any relevant..

    ti-bug.tar.gz

    output if everything works fine (without the SPI task)

    with the SPI task, ot-stack does not "boot" properly..

    maybe you can see something with the "map" file and/or the "out" file. appended both cases here

  • 0 in reply to Sascha Ehlers1
    Intellectual 435 points

    another question: how can i remove all those "debug" infos from my build.. creating a "release-build".. tested a map-file analyzer and found some big parts called "debug" :)

  • 0 in reply to Sascha Ehlers1
    Intellectual 435 points 
    movementSensor_task

     is just the renamed "empty_task"!

    which calls, before looping, the ot-stack.. which blocks anyhow..

  • 0 in reply to Sascha Ehlers1
    Intellectual 435 points

    some info, known by many other IDE's, would be cool.. like:

    RAM used 80% (xx from yy)

    Flash used 45% (xx from yy)

    .... :)

  • 0 in reply to Sascha Ehlers1
    TI__Mastermind 28010 points

    >> SPI task has 2048 stack.. question: what is the min. stack size? had used 1024 but those task randomly stopped working sometimes..
    >> ROV.. Never used before.. But, in my error-case I cant see any relevant..

    For this, you might consider changing the ROV view of Task from "Basic" to "Detailed". This will show "stackPeak", which can be used as indicator of stack overflow. For minimum, I'd recommend referring to section "3.6.3 Task Stacks" here. At a minimum I'd recommend a Task stack size to be as large as the idle task (you can use the stackPeak to see how low you can go on stack size).

    Thanks for sharing screenshots of the ROV -- so seems to me the SPI task is led_task in the ROV.
    The 
    Seems like the OStack_task is "ready" to run, and that another higher priority task is taking over.
    One experiment here could be to start the led_task after the code which prints out "coap server up and running".

    Can you share exactly where the project hangs (e.g. perhaps somewhere in OtStack_setupInterfaceAndNetwork) ?

    >> another question: how can i remove all those "debug" infos from my build.. creating a "release-build".. tested a map-file analyzer and found some big parts called "debug" :)

    I'll look into this and get back to you.

  • 0 in reply to Toby Pan
    Intellectual 435 points

    Thanks for that info with the stack sizes.. will investigate once we got this problem fixed!! ;)

    I exactly did that, too.. And even this breaks the ot-stack, that's why I thought something in the flash get's corrupted or overflown.. Because creating the led_task AFTER the "hang-causing"-code ..

    I will add the whole project! movement_sensor.tar.gz

    I guess the problem is this ot-stack-mutex, he's waiting for.. but no one claimed it.. dont know why this could happen! will start the debugger again and take a look!!

  • 0 in reply to Sascha Ehlers1
    Intellectual 435 points

    yeah, it is the OtRtosApi_Lock.. First call in setupNetwork, line 269:

    which never returns..

    even this does not help: tried to just init the semaphore again before entering the setup-network..

  • 0 in reply to Sascha Ehlers1
    TI__Mastermind 28010 points

    Thanks for sharing further debug info and the code.

    Looks like the led_task uses the SPI_Handle spi before it is opened (i.e. initSpi(true);).

    Can you try with initSpi(false);  ?

  • 0 in reply to Toby Pan
    Intellectual 435 points

    sorry, this was a left over from my testings.. this does not change anything..

    cause the function "ledTask_taskCreate" isn't called at all.. the led_task is not created nor running.. 

    cause the "movement_task" is stuck at starting the ot-stack.. and creating the led_task would be after that..

  • 0 in reply to Sascha Ehlers1
    Intellectual 435 points

    the strange thing, which I dont get..

    creating and starting the led_task AFTER the ot-stack, breaks the ot-stack .. oO what?! :D

    have no clue where to start, what to do.. tried different SimpleLink version.. same..

    I am on linux by the way.. using the GCC project..

  • +1 in reply to Sascha Ehlers1
    TI__Mastermind 28010 points

    I have tried a few permutations (gcc project in Windows CCS), with logs attached here.

    Description of logs:

    • led_en_nspi :    led_task created, comment out actual SPI_transfer  (and status check)
    • led_en_spi_nop :    led_task created, does not call SPI_open
    • led_end_spi_op :    led_task created, does call SPI_open
    • led_nen :    led_task not created
    • not_working :    logs taken from the provided not_working/movement_sensor.out
    • working :    logs taken from the provided working/movement_sensor.out

    In all cases, "ot interface up" is printed, and the led_task runs if it was created.
    The differences I see here, are related to how SPI is used :

    • if SPI_open is called OR SPI is not used at all, the logs progress (MovementSensor_TimerCb printouts, like ".. s: 0, i: 0 => 0").
    • if SPI_open is not called AND SPI use is attempted, then the logs do not progress (since led_task hangs due to attempting SPI_transfer with unitialized SPI_Handle spi -- led_task has highest priority of the 3 tasks).

    This is with led_task called after call to OtStack_setupInterfaceAndNetwork.

    I am running the code on the LP-CC2652RB, with no additional hardware attached.

    logs_and_images.zip

  • 0 in reply to Toby Pan
    Intellectual 435 points

    thanks for your investigations!

    that's strange.. maybe I have to test it on windows too!

    and trying to flash without CCS..

    coming back to you tomorrow, with hopefully some new informations.. :)

  • 0 in reply to Toby Pan
    Intellectual 435 points

    super weird.. after reading your message I was wondering how in the world could my "not_working" binary work on your site.. I mean, good that it does!

    so I tried to flash it again too.. used a serial-tool instead of the CCS.. which everytime erases the whole flash instead of being smart and trying to erase as less as possible.. and, boom.. worked, too!!

    had this problem once more this weekend, that a erase changed the behavior! but now I am aware of this and do not test several days strange stuff.. ^^

    two more things:

    - regarding the stack sizes and so on.. is there a way to access these ROV data during runtime? having some HW where it's not that easy to connect a debugger to..

    - binary size and removing those debug-symbols.. how to "build" a release-binary?

    awesome work toby! sorry for bothering you with my strange error..

    BR,

    Sascha

  • 0 in reply to Sascha Ehlers1
    TI__Mastermind 28010 points
    Sascha Ehlers1 said:
    - regarding the stack sizes and so on.. is there a way to access these ROV data during runtime? having some HW where it's not that easy to connect a debugger to..

    Consider using Task_stat() : https://dev.ti.com/tirex/content/simplelink_cc13x2_26x2_sdk_4_40_04_04/docs/tirtos/sysbios/docs/cdoc/index.html

    Sascha Ehlers1 said:
    - binary size and removing those debug-symbols.. how to "build" a release-binary?

    The debug_info are debug only, shouldn't be loaded onto the device itself.
    Related post : https://e2e.ti.com/support/tools/ccs/f/code-composer-studio-forum/84323/size-of-debug_info-section-changes-for-same-set-of-code

  • 0 in reply to Toby Pan
    Intellectual 435 points

    Hey Toby,

    another weird problem. ROV looks fine in both cases.. task do not exceed their limits.. 

    Somehow the JSON-library stops working properly..

    See here is the full project: heating-controller.tar.gz

    error occurred on the launchpad, too.. no need to connect something external, just flash it!

    output without the "heating-controller-task" created:

    output with the heatingcontrollertask created, started and running fine:

    here is the creation of the task, or not..

    tried to debug it, but since there is no code loaded for the JSON lib, its not working properly.. have no clue what to do next..

    could you take a look? =) Thanks!