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