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