DA14580 communication problems with higher supply voltage - follow up

⚠️
Hi there.. thanks for coming to the forums. Exciting news! we’re now in the process of moving to our new forum platform that will offer better functionality and is contained within the main Dialog website. All posts and accounts have been migrated. We’re now accepting traffic on the new forum only - please POST any new threads at https://www.dialog-semiconductor.com/support . We’ll be fixing bugs / optimising the searching and tagging over the coming days.
24 posts / 0 new
Last post
mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
DA14580 communication problems with higher supply voltage - follow up

We are using DA14580 on PAN1740 module.
The module is used on a coin battery powered products.
On the product a microcontroller communicates with DA14580 over UART.

We are experiencing with some modules connection problems.
We have noticed that it happens when battery voltage is higher like 3.1V - 3.3V.

This is new topic as I have further findings and question in previous one is 'completed'. I have received new units from production showing this problem.

Our production software is running without any problems as long supply voltage is below 3.25V.
With higher voltages it is running for a few seconds. I can see the product popping up in Windows Bluetooth pairing. If I am fast enough I can get PIN prompt. However I cannot complete pairing.

We have implemented basic support for RF Master (start/stop) for tests. It is possible to communicate with it over whole supply range (up to 3.6V).

To eliminate any possible mistake introduced by us, we used example application from SDK:
\DA1458x_SDK_5.0.4\DA1458x_SDK\5.0.4\projects\target_apps\ble_examples\prox_reporter\Keil_5\prox_reporter.uvprojx
It has been compiled without any modifications.
I can see Bluetooth device as DIALOG-PRXR when I start the Bluetooth module on our device.
Everything is fine up to 3.25V - I can see the unit and I can pair it in Windows (no PIN).
As soon as I increase voltage to 3.3V it is running again for few seconds only - right after power on the device is popping up, but I cannot complete pairing.
The module is booting over UART without any problems up to (at least) 3.6V.

The Panasonic module (PAN1740) we are using has very little external components (inductor, two crystals and few capacitors).

Voltages mentioned are supplies of our product. The module is supplied through IO pin of a microcontroller, so actual voltage on the module is lower (around 50mV less).

The problem is showing with some units only. Others work without any fuss (pairing and communication) up to 3.6V (and higher :-) ).

What could cause such behavior? Where should I search further?

Device: 
PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

Thanks for your question online. Would it be possible to provide the following data to have a better view on your issue?

  1. A current capture when the connection fails. I suspect that some of the devices miss connection events, so the connection cannot be maintained. What is the connection interval that you are using? If connection events are missing, then the connection interval should be gradually getting larger.
  2. A BLE Sniffer log when the connection fails.
  3. Current capture when the failure device is adverting. Are you able to count the advertising events? Are you missing any of the advertising events?

Thanks, PM_Dialog

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
1.

1.
In attachement current consumption of the module just right after power on and booting at 3.0V (OK), 3.2V (OK) and 3.3V (it fails).
It seems the software hangs after initialisation...

Connection interval is what prox_reporter BLE example has (min. 10ms, max. 20ms?).
However it depends on the negotiation with Windows 10 mostlikely - it has standard configuration.

2.
We do not have BLE Sniffer...
Can you recommend one?

 

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Current consumption of the

Current consumption of the module with changing voltage:

1. Module powered on and booted with 3.0V

2. Supply increased briefly to 3.3V

3. Supply reduced back to 3.0V

The module is not recovering with lower voltage.

omesa
Offline
Last seen: 8 months 3 days ago
Joined: 2014-12-07 12:17
hello,

hello,

maybe your problem is : " The module is supplied through IO pin of a microcontroller, so actual voltage on the module is lower (around 50mV less)." 

cheers

Siegmar

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
I have hardwired the module

I have hardwired the module to external power supply... No luck... It is stopping as soon as voltage is 3.3V...

omesa
Offline
Last seen: 8 months 3 days ago
Joined: 2014-12-07 12:17
hmmh ..... what happend, when

hmmh ..... what happend, when your controller make with an Portpin  RESET on the PAN1740 modul.

I have in my projekt the same module and mass production will start soon. My external controller can always RESET the modul. This is my hardware watchdog.

cheers

Siegmar

 

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
With our host software we

With our host software we check communication with the module all the time.
If it stops to respond host makes reset of the module.
The module powered with low voltage is working fine and the reset would be used only in case when the module is really stuck - I have not observed it.
As soon as voltage increases I can observe endless loop of resets...
The BLE is active for few seconds and then reset and again and again...
Periods of activity are enough for Windows to detect the device, once or twice I could complete pairing, but you can forget any comunication...

However, there is no communication with Dialog API example application (proxy), so the reset functionality in host is dissabled.
When it is stucks it is just stucks...

and once again - it is happening to only few units we have - all others are working fine up to 3.6V.
However this is affecting yield and extorts PCBA repairs...

cheers,
Michal

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi omesa, thanks for your

Hi omesa, thanks for your answer.

Hi mratajski, I’ll check your inputs and let you know as soon as possible.

Thanks, PM_Dialog

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

Again thanks for your inputs. Please correct my if anything is wrong/missing and kindly provide some further inputs on this. Then, I will escalate all your inputs internally for further analysis.

Issue description:

  • PAN14580 module is used in a custom board
  • DA14580 is powered through a coin cell battery
  •  The issue is appeared only in some modules, not at all devices. Can you indicate that the issue exists only on some of them? Are there any device which running at 3.3V supply voltage?

When the supply voltage is at 3.3V:

  • Some of the boards, start advertising for a while and then continually reset. How do you know that the chips enter an endless reset-loop?
  • BLE is active for few second, so are you able to connect?

Thanks, PM_Dialog

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
> PAN14580 module is used in

> PAN14580 module is used in a custom board
Yes, it is used on our BLE enabled product.

> DA14580 is powered through a coin cell battery
Yes, it is supplied using Lithium coin primary cell battery on problematic products (initial voltage 3.2-3.4V, nominal voltage 3.0V).

> The issue is appeared only in some modules, not at all devices. Can you indicate that the issue exists only on some of them? Are there any device which running at 3.3V supply voltage?
We do not perform production tests with 3.3V. We just test every unit with fresh battery (voltage of the battery is tested to be at least 3.2V or more) at the end of production.
Some units (few percent) are failing final BLE communication test with fresh battery.
Majority of produced units have no problem with initial (higher) voltage of the battery.
We do perform BLE tests of every PCBA at 3.0V as well. At this stage all units are communicating without any problems.

I have tested some failed samples from production - for them threshold voltage is around 3.25V. I observe problem above this voltage.
I have tested some passed samples as well – they are fine up to 3.6V.

> Some of the boards, start advertising for a while and then continually reset.
Yes, I can observe the correct name of the BLE device in Windows 10 Bluetooth pairing.

> How do you know that the chips enter an endless reset-loop?
I observe communication between host CPU and DA14580 with oscilloscope. I observe reset line as well.
The host application does not receive CTS from application running on DA14580 and it resets the Bluetooth module after time out – DA14580 is entering UART boot process, loads firmware and starts normal operation for few seconds and CTS is missing again...

> BLE is active for few second, so are you able to connect?
Among others I am able to read ADC converter values from DA14580 over the BLE from time to time (reset and ADC pooling loops are not synchronized),
when the problematic unit is supplied with 3.3V.
The pairing is perform at 3.0V before the test.

I managed to pair Bluetooth device in Windows 10 once or twice with 3.3V powered problematic unit.

I got impression it is getting worse if I increase voltage (like 3.4V or 3.5V) for problematic unit.

Regards,
Michal

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

Let me escalate your inputs internally. I’ll get back to you as soon as I have feedback from the Team.

Thanks, PM_Dialog

omesa
Offline
Last seen: 8 months 3 days ago
Joined: 2014-12-07 12:17
Hi Michal

Hi Michal
" The host application does not receive CTS from application running on DA14580 and it resets the Bluetooth module after time out – DA14580 is entering UART boot process, loads firmware and starts normal operation for few seconds and CTS is missing again..."

Whats happened, when your host resets not the PAN1740 ? It is still alive and advertising ?
What kind of host you have ?
Maybe for testing the modul, you can put for example a tag firmware on it.
Another idea, maybe the CTS Signal is too short or the serial communication is failed.
What is your baudrate ? Is it protected my a checksum ?
Sorry, this are only speculations, because we have not the hardware in front of us.
cheers
Siegmar

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Hi omesa,

Hi omesa,

When CTS is missing, the DA14580 is not advertising anymore.
CTS pulses are long enough for the microcontroller. When application running on DA14580 is hanging it does not send CTS anymore (short or long - verified with oscilloscope).
The application is based on examples from SDK.

We have put proxy firmware (example from Dialog SDK without any modifications as I have mentioned before already) on the module as well.
With higher voltage is the same - it is advertising for few seconds and then it stops. You can see with current drawn that the module is not transmitting anymore.
This means very simple application (no communication with host at all) is hanging by itself when there is higher voltage present.

Regards,
Michal

 

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

I’ve already escalated your issue internally. I will keep you updated.

Thanks, PM_Dialog

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

Can you please change the BANDGAP_REG [LDO_RET_TRIM] bitfield to a lower value? The default value for DA14580 and SDK5.0.4 is 0x0A, so change it to 0x09. You can also refer to DA14580datasheet and Table 26: BANDGAP_REG (0x50000028) for more information.  You will have to add the following line in the system_init() function before the periph_init() call.

void system_init(void)
{
  ...

// Check and read BD address
    nvds_read_bdaddr();

    SetBits16(BANDGAP_REG, LDO_RET_TRIM, 0x9);

    //Peripherals initilization
    periph_init();

 ...
}

Thanks, PM_Dialog

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Hi PM_Dialog,

Hi PM_Dialog,

It seems to be working! :-)
I got the proxy example working (I can pair it in Windows) up to 3.5V.
At 3.6V I cannot pair it as before.
I still need to do further measurements to be sure, but the question is: How low is reasonable to go with the bandgap voltage?
There is 3uH coil used (I will try to confirm it with Panasonic) as I have measured on other module.

Do you have any additional documentation for the register? The Table 95: BANDGAP_REG (0x50000028) is not giving much details and Note 18 is a little bit confusing...
What side effects are to be expected?

Regards,
Michal

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Hi PM_Dialog,

Hi PM_Dialog,

I have measured current consumption with bangap adjustments.
I have used simple scenario - read-out of battery voltage using ADC on DA14580 over Bluetooth, maintaining 3.0V voltage, so it works with and without  modification.
Our product consumes on average around 1.2mA with default bandgap configuration and around 2.4mA with value set to 0x9...

So the fix helps with higher battery voltage (not entirely, but it is fine for us), but it doubles current consumption while Bluetooth is used...
This is not exactly what we are aiming for... Do you have any other idea?

Regards,
Michal

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

Are you using the same firmware with same advertising intervals? Did you test it with any of our SDK examples, such as ble_app_barebone? You mentioned that the battery voltage is 3.0V instead of 3.3V (which was the problem). Can you please clarify it?

Battery voltage =  3.0 Volt

- When BANDGAP_REG[LDO_RET_TRIM] = 0x0A, current consumption is 1.2mA

- When BANDGAP_REG[LDO_RET_TRIM] = 0x9, current consumption is 2.4mA

Thanks, PM_Dialog

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Hello,

Hello,

3.3V - voltage of fresh battery cell (sometimes it is higher)
3.0V - nominal voltage of the battery
Our product must work with both voltages.
Bluetooth is falling/hanging at 3.3V on some units (as I have already described).

I have performed current measurements at voltage keeping Bluetooth alive on all units. Just to be sure there are no other effects.

The only difference in software is BANDGAP_REG[LDO_RET_TRIM]. All the rest has not been touched (including advertising intervals)

BANDGAP_REG[LDO_RET_TRIM] = 0x0A    --->   current consumption is 1.2mA
BANDGAP_REG[LDO_RET_TRIM] = 0x09    --->   current consumption is 2.4mA

Current consumption is increased regardless of problems at 3.3V. Both "good" and "bad" units need more current.

I have attached current measurements of one unit with both settings.

Regards,
Michal

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

Can you please undefine the CFG_POWER_OPTIMIZATIONS macro in da1458x_stack_config.h header file? After that, are you able to see any difference in the power consumption?

Thanks, PM_Dialog

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Hi PM_Dialog,

Hi PM_Dialog,

Thank you for new ideas :-)
Unfortunatelly I do not see any significant difference... On average it is only around 15-29uA less...  :-(

Regards,
Michal

PM_Dialog
Offline
Last seen: 1 week 6 days ago
Staff
Joined: 2018-02-08 11:03
Hi mratajski,

Hi mratajski,

My apologies for the late response. In fact that it is a custom PCB, there are several parameters involved and observe such a behavior in the system performance.  For instance, the following parameters might affect the system:

  • XTAL cut
  • PCB layer
  • PCB layout
  • Internal temperature
  • Positioning of the XTAL
  • Impact on overall system performance

The resolution is to change LDO_RET_TRIM bit-field to a lower value (as previously suggested) and keep the system functional in the known operational limit.

Thanks, PM_Dialog

mratajski
Offline
Last seen: 1 year 1 week ago
Joined: 2019-02-21 11:32
Hi PM_Dialog,

Hi PM_Dialog,

Thank you!
It seems I need to push module manufacturer now...

Best Regards,
Michal