CC2640: NO ADVERTISEMENT - SIMPLE PERIPHERAL DEVICE - CC2640

Hi,

Thank you for reaching out. Can you share the SDK version you are using? Are you able to reproduce this behavior reliably? Can you try connecting a debugger when the behavior occurs and sharing the call stack?

Best Regards,

Jan

Hi Jan,

Thank you for your quick response.

Please find the answers for the queries raised in below,

1. Can you share the SDK version you are using?

     SDK used in our project is 4_30_00_08

2.Are you able to reproduce this behavior reliably? 

The issue will be resolved by re-flashing the software. But couldn't recreate this behavior again reliably.

3. Can you try connecting a debugger when the behavior occurs and sharing the call stack?

We didn't tried connecting debugger because once we reflash we don't know how to recreate this issue again.

Hi,

Understood, thank you for the additional details. If possible, then I would recommend updating your SDK to the latest 5.30 release. There have been many fixes and improvements in the SDK since 4.30, so its possible the behavior you are seeing may have been solved by a new release. How many devices was this behavior seen in? Can you describe the environment where the devices were located?

Best Regards,

Jan

Dear Jan,

Thank you for your response!

Please find the answers for the queries raised in below.

How many devices was this behavior seen in?

Dispatching approximately 10 thousand products per two months issue found in 20 to 25 products among this

2.  Can you describe the environment where the devices were located?

The Ble chip is used in two-wheeler speedometer

Dear Jan,

We have read the defected ble chip software through smart rf flash programmer.

And flash the same into another working ble chip

And found the same behavior (BLE chip does not initiate advertisement) observed in the good working product.

Please help us to  address this issue. Any spinlock happens if yes how to identify why happened?

Hi,

To clarify, you are saying that you read out the entire flash of the device and then written that flash to the entire flash of a working device?

Best Regards,

Jan

Hi Jan,

We have read memory from 0x00000000 to 0001FFF2

Hi,

Understood. Thank you for clarifying.Can you connect a debugger to your device while it si in the faulty state and report what the call stack looks like?

Best Regards,

Jan

Hi,

The issue will be recovered while reflashing.

Suppose if we connect debugger with ble chip then it leads to reflahing.

Please let me know how to debug the software without reflashing

Hi,

It should be possible to connect the debugger to the device without causing a reset. So if you are able to flash your image and manifest the behavior, then you should be able to connect the debugger without resetting and extract debug information from the running target. Please see the following E2E thread:

https://e2e.ti.com/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/432770/cc2640-connecting-to-a-running-target

Best Regards,

Jan

Dear Jan,

Read Bin file from working (Advertisement happening) and not working (Advertisement not happening) meters.

Some analysis done as below please check this,

UART communication sequence between Controller and BLE chip 

For every ON cycle controller sending BLE name to the BLE chip.

The BLE chip receiving the BLE name and write into SNV using osal_snv_write API.

While analyzing both bin files (Working and Not working) we found some difference in the address of Flash memory(Started at 0001E000) where SNV located.

In Good working  "bin file" there is no change in the BLE name which was written in SNV on every "ON" cycle.

But when checking Not working  "bin file " found changes BLE name which was written in SNV on every "ON" cycle.

Note: Controller sending same name for every "ON" cycle.

Please guide us to know what are the reasons for this change in BLE name on SNV (Letters in the "BLE Name" replaced with junk values)

Example : 

Not working Meter

Controller to BLE - "SAS020000000"

Data in SNV - "SA#020000000"

Conclusion : Both not same

Working Meter

Controller to BLE - "SAS020000000"

Data in SNV - "SAS020000000"

Conclusion - Both same

One more analysis done as below please check this also for your reference,

Introduce noise(Help of Function Generator) in the BLE Tx pin in a meter and did 500 "ON" cycle finally the issue was recreated.

Then read the bin file.

Compare this bin file with Not working bin file and found similar changes in BLE name written in the SNV.

Note: Snip of working and not working bin file (BLE name in SNV) attached here for your reference

Not working bin - BLE Name in SNV - Highlighted portions are changed - Controller sending BLE Name is SAS020544170

Conclusion : Changes in BLE Name sending from controller

Working bin - BLE Name in SNV - Controller sending BLE Name is SAS020000010

Conclusion : No change in BLE Name sending from Controller

Hi,

Thank you for the additional details, I am not sure why that would happen at this time. I believe we need to connect a debugger (without resetting the device) to monitor the state of the application. Is that a possible debug strategy that we can follow?

Best Regards,

Jan

Dear Jan,

In our product we are running two tasks.

For debugging purpose activating LED from both tasks.

When switch ON the board the software is running properly till the execution of BIOS_start()  function.

But both tasks not getting executed and it was confirmed from the status of the LED.

Can you clarify what is reason for the tasks not getting executed. Even BIOS_start() function is executed from main function.

Hi,

My apologies for the delay. I was out of office last week. Does the same behavior occur if you start the tasks after the BIOS_start() function has completed?

Best Regards,

Jan

Dear Jan,

The following debugging strategy used for analysis for your reference,

In the working software Enabled LED blinking for analysis - built the software and generated the bin file.(Test software)

Read the defect cluster bin file and copied data from (SNV 0X0001E000). till last line.

Replace the bin file portion (0x0001E000) of the test software  with copied defect cluster bin data.

Analysis done with reference to LED blinking.

Observation:

1."static uint16 compactPage()" function in nvocop.c  file was triggerd.(Path:C:\ti\simplelink_cc2640r2_sdk_4_30_00_08\source\ti\blestack\services\src\nv\cc26xx)

2.With in this function there is a while loop.

3.In the while loop the ble software getting strucked while executing the "void HalFlashRead(uint8 pg, uint16 offset, uint8 *buf, uint16 cnt)" function after some iterations.

4.With in the "HalFlashRead" function the software getting strucked when the pointer variable "ptr" value become 0x00020000 (Address stored in the pointer variable)

Query:

1.When this "static uint16 compactPage()" will be triggered? (Any failure case ??)

2.In good working software "static uint16 compactPage()"  is not getting triggered.

3.Please explain the purpose of  this "static uint16 compactPage()" function.

4.Why the code getting structed when "ptr" value become 0x00020000 (Address stored in the pointer variable ptr) while the execution of  "HalFlashRead()"

Hi,

Hari Shankar Elango said:

1.When this "static uint16 compactPage()" will be triggered? (Any failure case ??)

The API is called whenever a compaction must take place in the SNV region of flash.

Hari Shankar Elango said:

2.In good working software "static uint16 compactPage()"  is not getting triggered.

I would expect this API to be called whenever it is time to do a compaction, so this may be telling us that the issue occurs only when a compaction must be performed.

Hari Shankar Elango said:

3.Please explain the purpose of  this "static uint16 compactPage()" function.

The API is used to perform compaction on the SNV which are done to minimize the umber of erase cycles. A compaction should only happen when a sector has 80% invalidated data. The following section of the user's guide provides some more details on this:

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-common/flash_memory-cc2640.html#simple-nv-flash-storage-overview

Hari Shankar Elango said:

4.Why the code getting structed when "ptr" value become 0x00020000 (Address stored in the pointer variable ptr) while the execution of  "HalFlashRead()"

I am not sure why this would happen. Can you use the memory browser to see what is located at this address?

Best Regards,

Jan

Dear Jan,

Can you please list down the reasons for "no advertisement" in BLE chip even it is powered (hardware and software cause)

Hi,

There could be a few different reasons for why a device may not be advertising:

1. A connection may have been formed. By default, the SDK examples stop advertising if the max number of connections has been reached.

2. Advertising was disabled by an API

3. Too many connections and data transfers occuring which causes advertising to be skipped as connection events are given higher priority.

Is the device not advertising when you expected it to? Can you check if the advertising disabled event has been received by the application?

Best Regards,

Jan

Dear Jan,

Please clarify below mentioned points,

1.What does the first 4 bytes of configured SNV portion represents.(In our product starting address of SNV portion is 0x0001E000)

2.And also clarify, why this function "static uint16 compactPage()" triggered only when the value in the first four bytes (which is highlighted in the below image)

is 00. If any values(01,FF) present atleast in any one of these bytes the function "static uint16 compactPage()" is not triggered.

3.How do we check the  OSAL_SNV configuration in BLE 5 stack code. While checking predefined values not getting any information.

4.Suppose If the configuration as like below what is meaning of that?

OSAL_SNV = 1(What will be the SNV configuration) or

OSAL_SNV = 2(What will be the SNV configuration) or

OSAL_SNV = 0(What will be the SNV configuration) or

5.What is default OSAL_SNV value ??

Dear Jan,

Please explain the below mentioned points

1.Please explain about Active page and transfer page in detail.

2.Relation between SNV header(First four bytes of SNV start bytes) and Active page and transfer page

3.In below mentioned code snip, whenever the else if condition will be triggered.

if ( pgHdr == NV_ACTIVE_PAGE_STATE )
  {
        HAL_ASSERT_FORCED();
        UART_write(UartHandle, &testconn_1_0[0], 6);
        findOffset();

   }
  else if ( pgHdr == NV_XFER_PAGE_STATE)
  {

       findOffset();
       compactPage();

   }

Hi,

Hari Shankar Elango said:

1.Please explain about Active page and transfer page in detail.

I believe an active page is the page that is being read from or written to. I believe the transfer page is the page used during a compaction to transfer the data.

Hari Shankar Elango said:

2.Relation between SNV header(First four bytes of SNV start bytes) and Active page and transfer page

I believe the 2nd byte says if the page is active or transfer or whatever its status is.

Hari Shankar Elango said:

3.In below mentioned code snip, whenever the else if condition will be triggered.

if ( pgHdr == NV_ACTIVE_PAGE_STATE )
  {
        HAL_ASSERT_FORCED();
        UART_write(UartHandle, &testconn_1_0[0], 6);
        findOffset();

   }
  else if ( pgHdr == NV_XFER_PAGE_STATE)
  {

       findOffset();
       compactPage();

   }

I think the else if would happen if the page header was being used during a transfer before the function was called. Since this is in the init function its possible this happens if the device is reset while a transfer is occurring.

Best Regards,

Jan

Dear Jan,

Thank you for your valuable support !

The GAP configuration is show in the below image.

Our question is  what will happen because of the setting "bonding = TRUE"

If we make it "bonding = FALSE" then what will happen.

Please explain in detail.

Is there any relation between justwork pairing, Bonding method?

Note : In our product we are not using passkey method so configured "mitm = False"

Dear Jan,

In BLE application code we are writing BLE name in the SNV as mentioned in below image.

when we read the SNV memory through smart Rf connect, found the header 0X81 and length 12 automatically modified. Please explain why these static values getting modified or what are reasons behind this modification the snip attached below.

Note : Please clarify the previous query also

Hi,

Can you try reading that address using UniFlash and checking if the address is also modified there?

To clarify, you are asking how the SNV works if bonding is enabled or disabled?

Best Regards,

Jan

Hi [Jan],

Please find the answers for the queries raised in below,

 1.Can you try reading that address using UniFlash and checking if the address is also modified there?

Yes, I was able to read the SNV using UniFlash and confirmed that the data is present. However, I observed that the data stored is not the valid data I intended. In the code, I tried to store the following data:

 - ID: "0x81 0x00"
- Length: "0xC0 0x00"
- Followed by 12 bytes of data.

 The command used is: 
osal_snv_write(0x81, 0xC0, &BLE_Tx_Buff[0])

 But, In SNV it is getting written as below:
- "89 00 C0 00 xx xx xx......"
- "A1 00 C0 00 xx xx xx......" and similarly

Modified ID's

Modified Lengths

As seen in the UniFlash screenshot (attached for your reference), the ID region is getting manipulated/corrupted during the write process. The ID appears as "89 00" or "A1 00" instead of the expected "0x81 0x00", and similarly, the length byte is being modified to "0C 04" or "0C 80" instead of the intended "0x0C 0x00".

Could you help clarify what might be causing this issue? Specifically, what could be the root cause of these discrepancies in the ID and length during the write process?

2.To clarify, you are asking how the SNV works if bonding is enabled or disabled? 

Yes, I am asking how SNV works and also want to know is there any difference in BLE connectivity.

Looking forward to your response.

Hi,

Thank you for the detailed breakdown. At a glance, I am not sure why the behavior is happening. The following section of the user's guide explains how the SNV should work:

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/blestack/ble_user_guide/html/ble-stack-common/flash_memory-cc2640.html#flash

In the link there is also a code snippet for using the SNV. Can you try adding that code snippet to an example project and seeing if you see the same behavior on your side?

Best Regards,

Jan

Hello Jan,

Thank you for your support!

Issue Overview

Bluetooth functionality suddenly stopped working, and there was no broadcast.

I reviewed the link you provided, “Flash Memory Layout and Usage,” and attempted to understand the root cause of the issue. However, I was unable to pinpoint the problem.

Initially, I observed that only the ID and Length fields were being modified during the SNV write process. Below, I explain the issues in detail for better understanding:

Detailed Observations

Issue 1: ID is being modified during the SNV Write process

• The ID is randomly modified, and this behavior occurs with a 1 in 20 probability (not consistent).

Issue 2: Length is being modified during the SNV Write process

• The Length field is intermittently altered with a similar probability as Issue 1.

Both issues are random and do not follow a consistent pattern. Despite referring to the shared documentation and the Technical Reference Manual (swcu117i), I could not determine the root cause.

Note:
In the osal_snv_write(0x81, 0xC0, &BLE_Tx_Buff[0]) function:

• The user does not have direct access to modify the ID or Length fields.
• The user can only transfer 1 byte of ID and 1 byte of Length.
• Internally, the SDK performs word-write operations and typecasts these values into 2 bytes.

Additional Observed Issues

Issue 3: Intermittently, the ID and data are modified and written as FFFF instead of 81 00

• This behavior continues until the full remaining SNV memory is filled with FFFF.

Issue 4: Some portions of the data are intermittently modified and written as FFFF

• This issue also continues until the full remaining SNV memory is filled with FFFF.

Issue 5: 16 bytes (or more) of data are written outside the SNV stack region

• Data spills into unintended memory regions.
• Some data is being written into the CCFG stack memory, which is not as per design and violates the intended memory map configuration.

This BLE module is used in a battery-powered application, and there are no possibilities of low voltage scenarios. However, there is a negligible chance of voltage fluctuations due to external factors.

During the osal_snv_read process, if voltage fluctuations occur, what would be the potential impact on data?

 

Please review these details and provide your insights on resolving these issues. Let me know if additional information is required.

 

Thank you!

Hi,

Thank you for the in-depth debugging and sharing the findings! This is very helpful! I agree that this does seem strange. I have a few more things I would like to try

1. Could you try pausing the execution of the device after the "stop advertising" issue occurs? I would like to see if the device is stuck somewhere.

2. Did you get a chance to reproduce this on the latest 5.30 SDK? Its possible this may have been addressed already in a subsequent release.

3. Can you monitor what the heap/stack usage is during program execution. It would be helpful to know if we are getting near the max heap size when the issue starts occurring.

4. You mentioned that the device is running on a battery. I do not expect this to be an issue, but for completeness and to fully rule out the battery could you try to reproduce this behavior will running off a power supply?

Best Regards,

Jan

1. “Could you try pausing the execution of the device after the "stop advertising" issue occurs? I would like to see if the device is stuck somewhere.

We observed that the execution is getting stuck at the following line in the code(during the compaction process):

static uint16 compactPage() HalFlashRead(NV_PAGE, srcOff, (uint8 *) &hdr, FLASH_WORD_SIZE); 

while (cnt--)

{

  *buf++ = *ptr++;

}

The issue appears random and occurs after multiple compaction cycles, which makes it difficult to predict when exactly this behavior happens

2. Did you get a chance to reproduce this on the latest 5.30 SDK? It's possible this may have been addressed already in a subsequent release.

We are currently using simplelink_cc2640r2_sdk_4_30_00_08 as the base for our application development.

At the moment, we are not in a position to upgrade to the 5.30 SDK due to project dependencies and time constraints.

Our first and foremost priority is to identify the root cause of this failure in the current SDK version.

3. Can you monitor what the heap/stack usage is during program execution? It would be helpful to know if we are getting near the max heap size when the issue starts occurring.

Could you please guide us on where and how we can monitor the heap/stack usage during execution? Are there specific tools or methods you recommend for this?

The problem does not occur consistently; it arises only after multiple compaction cycles across multiple boards, making it challenging to track the code behavior.

4. You mentioned that the device is running on a battery. I do not expect this to be an issue, but for completeness and to fully rule out the battery could you try to reproduce this behavior while running off a power supply?

Yes, we have already performed bench simulations using a power supply, and the issue is still reproducible.

With Regards,

Elango

Hi Elango,

Thank you for the details. Regarding the heap profiling, we have a guide on howto do this in the link below:

https://dev.ti.com/tirex/content/simplelink_cc2640r2_sdk_5_30_00_03/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-memory-problems

I'm glad we were able to rule out the power supply. To confirm, are you seeing this on a launchpad or custom board? If it is on a custom board, then could you reproduce this on a LaunchPad? This will allow me to reproduce on my side to hopefully speed up debugging.

Best Regards,

Jan

Hello Jan,
Thank you for your feedback and continued support!

Jan: Are you seeing this on a launchpad or custom board?
Reply: I am using a custom board for development and I have seeing this on my custom board.

Jan: If it is on a custom board, then could you reproduce this on a LaunchPad? This will allow me to reproduce on my side to hopefully speed up debugging.
Reply:

1. I can try to reproduce the issue on a LaunchPad, but there are some constraints in doing so. The BLE module communicates with the main application microcontroller, and testing this setup on a LaunchPad would require both hardware and software modifications.
2. Additionally, during testing on my custom board, it took more than 400 compaction cycles to recreate this issue. In debug mode, it might be challenging to replicate the same behavior on a LaunchPad.

Could you suggest an alternative approach to help identify and fix this issue more efficiently?

Looking forward to your suggestions!

With regards,
Elango

Hi Elango,

Thank you for confirming the HW setup. If you are performing writes at a certain rate in your custom application then maybe it is possible to simply perform dummy writes based on a timer that executes at the same rate. This may allow the behavior to be reproduced in an automated fashion. Having a project that quickly & reliably demonstrate the behavior will be very helpful for debugging on my side and on R&D's side if necessary. Seeing if the behavior occurs on the LP would also narrow out any HW causes.

Best Regards,

Jan