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.

CC2640R2L: Advertisement stops after SDK migration v1.50.00.58 → v5.30.00.03

Part Number: CC2640R2L
Other Parts Discussed in Thread: CC2640

Tool/software:

Hi,

We are migrating SDK from v1.50.00.58 to v5.30.00.03 using the following migration guides.

After the sdk upgrade, We are running into the issue where cc2640 would stop advertising after around 15 minutes. Something we also reported in the past but could not find solution. Please note that with old sdk, we never faced the same issue as we already around fifty thousand of devices already in the field.

When device stops advertising, we noticed that power module stops sending notifications registered by application using Power_registerNotify. However, the spi communication between host processor and cc2640 works as expected. We also tried to debug using ROV but we didn't see anything there.

Our device uses spi trasport for communication with the host processor. We also noticed that we if we comment out Power_registerNotify that registers spiPostNotify callback with wake up from standby event then device continue advertising for the indefinite period.

Can you please help/guide us further on how to debug/fix this issue?

Please find below the logs  for the last power state before device stopped advertisement.

#020875 [ 899.770 ] INFO: (../Driver_SPI/SPICC26XXDMA.c:1118) SPI:(@40000000) CPU freq: 48000000; SPI freq to 5000000
#020876 [ 899.770 ] INFO: (../Startup/main.c:411) Power Event 8
#020877 [ 899.770 ] INFO: (../Startup/main.c:411) Power Event 16
#020878 [ 899.815 ] INFO: (../Startup/main.c:411) Power Event 1
#020879 [ 899.983 ] INFO: (../Startup/main.c:411) Power Event 4
#020880 [ 899.983 ] INFO: (../Driver_SPI/SPICC26XXDMA.c:1118) SPI:(@40000000) CPU freq: 48000000; SPI freq to 5000000
#020881 [ 899.983 ] INFO: (../Startup/main.c:411) Power Event 8
#020882 [ 899.984 ] INFO: (../Startup/main.c:411) Power Event 16
#020883 [ 900.028 ] INFO: (../Startup/main.c:411) Power Event 1
#020884 [ 900.199 ] INFO: (../Startup/main.c:411) Power Event 4
#020885 [ 900.199 ] INFO: (../Driver_SPI/SPICC26XXDMA.c:1118) SPI:(@40000000) CPU freq: 48000000; SPI freq to 5000000
#020886 [ 900.199 ] INFO: (../Startup/main.c:411) Power Event 8


  • Hello Bhavesh,

    Thanks for reaching out.

    May I ask if this is an out of the box example? Are you still using the simple_np project? What modifications have you done?

    I see from the previous post, that some progress was made, "After this change the device can advertise and TxRx data non-stop!" is this still the case, if not what have changed?

    BR,

    David.

  • Hi David, Thanks for getting back.

    This is obviously not the out of box example as we have been developing this project since quite few years already. We started with the out of box example with sdk v1.50.00.58. What was tried in the previous post was more of an experimental change. We forced the RF power constraint to disallow it from stitching power states. This is not a feasibly solution.

  • Hello Bhavesh,

    I am looking this in more detail. From the events you shared previously, I can see the following sequence that makes sense from the standby policy:

    1. Power Event 8: The device is waking up from STANDBY (this event is sent later during wakeup, after interrupts are re-enabled) .
    2. Power Event 16: The high frequency (HF) clock source has been switched to XOSC_HF.
    3. Power Event 1: The device is entering the STANDBY sleep state.
    4. Power Event 4: The device is waking up from the STANDBY sleep state.

    Can you confirm the last event you get before adv is Power Event 8? If this is the case then there is an issue happening while switching to the XOSC_HF which I am tracking down (PowerCC26XX_switchXOSC_HF). May I ask if you are using a custom board, if this is the case (which I assume it is considering the previous answer), could you evaluate if the same issue (advertisement ends after a period of time) also happens when you flash one of the out of the box examples from the SDK?

    BR,

    David.

  • Hi David,

    The advertisement works with out of box example simple_np. To add more to the information provided, if we comment out the transportWrite then also device also advertises indefinitely.
    The device always stops advertising exactly after 900 seconds after boot.
    The last event is indeed power event 8. We were also suspecting the issue with clock switching. We added more logs inside the function configureXOSCHF when every time switching happens. Please take a look

    #060069 [ 899.750 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1395) turn off OSC_XOSC_HF
    #060070 [ 899.821 ] INFO: (../Startup/main.c:411) Power Event 1
    #060071 [ 899.854 ] INFO: (../Startup/main.c:411) Power Event 4
    #060072 [ 899.854 ] INFO: (../Driver_SPI/SPICC26XXDMA.c:1118) SPI:(@40000000) CPU freq: 48000000; SPI freq to 5000000
    #060073 [ 899.854 ] INFO: (../Startup/main.c:411) Power Event 8
    #060074 [ 899.854 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1367) use OSC_XOSC_HF
    #060075 [ 899.855 ] INFO: (../Startup/main.c:411) Power Event 16
    #060076 [ 899.858 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1395) turn off OSC_XOSC_HF
    #060077 [ 899.929 ] INFO: (../Startup/main.c:411) Power Event 1
    #060078 [ 899.960 ] INFO: (../Startup/main.c:411) Power Event 4
    #060079 [ 899.960 ] INFO: (../Driver_SPI/SPICC26XXDMA.c:1118) SPI:(@40000000) CPU freq: 48000000; SPI freq to 5000000
    #060080 [ 899.960 ] INFO: (../Startup/main.c:411) Power Event 8
    #060081 [ 899.960 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1367) use OSC_XOSC_HF
    #060082 [ 899.961 ] INFO: (../Startup/main.c:411) Power Event 16
    #060083 [ 899.964 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1395) turn off OSC_XOSC_HF
    #060084 [ 900.035 ] INFO: (../Startup/main.c:411) Power Event 1
    #060085 [ 900.069 ] INFO: (../Startup/main.c:411) Power Event 4
    #060086 [ 900.069 ] INFO: (../Driver_SPI/SPICC26XXDMA.c:1118) SPI:(@40000000) CPU freq: 48000000; SPI freq to 5000000
    #060087 [ 900.069 ] INFO: (../Startup/main.c:411) Power Event 8
    #060088 [ 900.069 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1367) use OSC_XOSC_HF
    #060089 [ 900.074 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1395) turn off OSC_XOSC_HF
    #060090 [ 900.173 ] INFO: (/home/bhavesh/ti/simplelink_cc2640r2_sdk_5_30_00_03/source/ti/drivers/power/PowerCC26XX.c:1367) use OSC_XOSC_HF

  • Hello Bhavesh,

    Do you have a TI launchpad to try to reproduce this issue there? I am assuming this is a custom board correct?

    BR,

    David.

  • Hi David, This is indeed a custom board. We can try to reproduce it on TI launchpad with our code.

  • Hello Bhavesh,

    Okay, please let me know what is the result on the TI launchpad.

    BR,

    David.

  • Hi David? Did you had the chance to look into this issue? Yes we also reproduce on the launchpad.

  • Hello Bhavesh,

    Thanks for confirming that. I will not have to try to reproduce on my side with the launchpad.

    You mentioned a migration from 1.50 to 5.30 following the guides, did you do it directly to 5.30 or using each of the migrations steps (1.5 -> 2.2, then 2.2 -> 2.3, etc)?

    In addition, have you set any new periodic events?

  • Hi David,

    Thanks for your help. We found the bug in our code which was causing the cc2640 to stop advertising after performing a spi write. The spi_transaction buffer in npi transport layer was on stack which was scheduling later for the dma transfer. This part of the code was modified by us. We were surprised that how was it even working with an old sdk.