1. Example Description

Both DA14531 and DA14585/586 devices comprise three main reset signals that can be triggered from different sources, the reset signals are:

  • POR : Triggred when VDD (VBAT_LOW and VBAT_HIGH rails only for the DA14531) voltage crosses the minimum voltage threshold value or optionally triggered by a configured GPIO or if the RST pad is held high for more than the POR_TIMER_REG value.

  • HW RESET : Triggered by the RST pad (P00 for the DA14531), the watchdog, or when waking up from sleep while having the RESET_ON_WAKEUP bit set.

  • SW RESET : Triggered when setting the SW_RESET bit.

The current SW example demonstrates how to issue and identify the different kinds of reset on the DA14531 and DA14585/586 devices as well as identifying if the device run into a Hardfault or an NMI interrupt.

The DA14531 includes a special register that indicates the reset source previously occured (RESET_STAT_REG) while in order to identify the reset source on the DA14585/586 devices registers that retain their values, through the different kinds of reset signals, are used. The SDK 6.0.14.1114 includes a weak function in the system_init() which can be implemented on user space in order for the application to be aware of the current reset.

The example can be downloaded from Here

2. Key Features

  • Store data in the uninitialized section of the Retention-RAM for tracking an NMI or a Hardfault.

  • Detect the following reset signals:

    • Hardware reset

    • Software reset

    • HW Reset by WDOG expiration (only for DA14531)

    • Power-on-Reset

  • Using UART2 for debugging purposes.

  • 128-bit UUID custom profile

    • For reading the current reset reason.

    • For issuing a reset.

3. SDK modifications

The current example uses the un-initialized data section in order to store identification flags for the application code to be aware if an NMI or a Hardfault has occured. The identification flag is preceded and followed by 32bit magic values that act as memory integrity check.

When the fw is build with the CFG_DEVELOPMENT_DEBUG flag defined, and an NMI or a Hardfault occurs, will halt the processor either in a while(1) loop or in a breakpoint in order for the developer to check the issue via the debugger. For reseting the device as soon as one of those interrupts occur the CFG_DEVELOPMENT_DEBUG flag should be undefined. In that case the fw will issue a SW reset and start execution of the bootrom. By default the example has the flag undefined for demonstrating the fault recognition functionality.

For setting the fault flags minor changes has to be applied in the SDK in order to set the corresponding flag if the NMI or the Hardfault handler executes. The user will have to add:

  • For the Hardfault:

    • Include the user_reser_mechanism.h file in the hardfaut_handler.c:

      #include "user_reset_mechanism.h"

    • In the top of the HardFault_HandlerC() function, invoke the function:

      user_set_hardfault_flag();

  • For the NMI:

    • Include the user_reser_mechanism.h file in the nmi_handler.c:

      #include "user_reset_mechanism.h"

    • At the top of the NMI_HandlerC() function, invoke the function:

      user_set_watchdog_flag();

4. HW and SW configuration

  • Hardware configuration

    • This example runs on DA14531 and DA14585/586 Bluetooth Smart SoC device.

    • Any of the following Development Kits can be used :

      • DA14531 Daughter board + DA145xxDEVKT-P PRO Motherboard

      • DA14531 SmartBond TINY™ Module + DA145xxDEVKT-P PRO Motherboard

      • DA14585 Daughter board + DA145xxDEVKT-P PRO Motherboard

      • DA14586 Daughter board + DA145xxDEVKT-P PRO Motherboard

    • For running the example on a DA14531 Daughter board + DA145xxDEVKT-P PRO Motherboard the following configuration is required.

      • Connect the DA145xx Pro Development Kit to the host computer.

      • UART TX on P0_6 for DA14531 (Place wire between J1:17 and J2:27) for printing functionality.

      DA14531_connection_wires

    • For running the example on a DA14585/586 Daughter board + DA145xxDEVKT-P PRO Motherboard the following configuration is required.

      • Connect the DA145xx Pro Development Kit to the host computer.

      • UART TX on P0_6 for DA14585/586 (Place wire between J1:17 and J2:11) for printing functionality.

      DA14531_connection_wires

  • Software configuration

This example requires:

  • SmartSnippets Toolbox 5.0.16.

  • SDK6.0.14

  • SEGGER’s J-Link tools should be downloaded and installed.

  • A simple serial terminal should be installed on the PC (e.g. Putty or Teraterm).

  • The example provides also the below options:

    • define CFG_PRINTF (in da1458x_config_basic.h) for printing the reset reason and faults when start up (by default enabled in the SW example).

    • define CFG_SPI_FLASH_ENABLE (in da1458x_config_basic.h) for powering off the flash in case the device boots from the external SPI memory (by default enabled in the SW example).

5. Custom profile

An 128-bit UUID custom profile is included with 1 custom service. The BLE database contains 2 characteristics as shown in the table below

Custom Service 1 Characteristic Values and Properties
Name Properties Length(B) Description
Control Point Write 1 Accept commands from peer
Reset Detection Read 2 Source of the reset and fault in the peer device

Note: For more information on adding characteristics in a custom service database and creating Custom Profiles, see this tutorial.

User can explicitly cause a RESET by writing the appropriate value in the “Control Point” characteristic, as shown in the table below:

Values of Control Point characteristic
Value Enumeration Description
0x01 TRIGGER_WDOG_NMI Trigger the WDOG timer to generate an NMI interrupt at 0. The device if DEVELOPMENT_DEBUG is undefined will issue a SW reset
0x02 TRIGGER_HARDFAULT Trigger a Hardfault interrupt by unaligned memory access, this will cause the Hardfault handler to execute and in turn by waiting in a while(1) loop the NMI Handler will issue a SW reset.
0x03 TRIGGER_WDOG_RESET Trigger the WDOG timer to generate a HW reset (NMI interrupt will not occur)
0x04 TRIGGER_SW_RESET Trigger a Software Reset be setting the SYS_CTRL_REG[SW_RESET] bitfield to 1.
0x05 TRIGGER_HW_RESET Trigger a HW reset by enabling RESET_ON_WAKEUP, sleep is enabled and on wake up the device will reset. The same reset can also be triggered by the RST pad or P00 (for the DA14531).
0x06 TRIGGER_POR_RESET Trigger a POR reset on P0_5 when pin goes high. The code will activate the internal pull up and de-activate sleep until the reset occurs.

Table below demonstrates the different values of the “Reset Detection” characteristic:

Values of Reset Detection characteristic
Description Value (DA14531) Value (DA14585/586)
No RESET 0x0000
SW reset NMI has occured 0x0204
SW reset Hardfault has occured 0x0304
HW Reset caused by Watchdog 0x000E 0x0006
Software Reset 0x0004
Hardware Reset 0x0006
Power on Reset 0x000F

Note: The DA14585/586 is not able to identify the difference between a HW reset that occured from the watchdog or a common HW reset occured from the RST pad or RESET_ON_WAKEUP.

Note: Since the DA14585/586 doesn’t include a HW for reset identification the determination of the reset type is done via reading register values that either retain their state depending on the reset. The values assigned for the reset types in the DA14585 by the fw are identical to the ones that the DA14531 HW uses.

6. Reset Mechanism in DA14531

See Section 5 in DA14531 datasheet for more detailed information on RESET functionality.

As mentioned the DA14531 includes a special register for identifying the

Values of RESET_STAT_REG
Description WDOGRESET_STAT SWRESET_STAT HWRESET_STAT PORESET_STAT Value (hex) Macro Definition
WDOG 1 1 1 0 0x0E WDOGRESET_VAL
Software Reset 0 1 0 0 0x04 SWRESET_VAL
Hardware Reset 0 1 1 0 0x06 HWRESET_VAL
Power-on-Reset 1 1 1 1 0x0F PORESET_VAL

For more information on RESET_STAT_REG, see Table 270 in DA14531 datasheet.

7. How to run

7.1. Initial Setup

  • For the initial setup of the example please refer to this section of the dialog support portal.

  • For the DA14531 Getting started guide you can refer to this link.

  • For the DA14585/586 Getting started guide you can refer to this link.

7.2. Compile & Run

  1. Open the project via Keil µVision 5.

  2. Select the proper build for the corresponding device (DA14531, DA14585, DA14586).

    first_boot_msg

  3. Build the project and load it to target. The project can be run either from System-RAM or SPI Flash.

    Note: In case of SPI Flash, the Flash Programmer from SmartSnippets Toolbox should be used. Refer to the user manual to get familiar with the SmartSnippets Toolbox.

  4. Set up a serial terminal session by selecting the proper virtual COM port and set the port configuration as shown below:

    • Baudrate: 115200

    • Data: 8 bits

    • Stop: 1 bit

    • Parity: None

    • Flow control: none

    Note: Refer to Section 10 in Get Started tutorial for more information on enabling the UART for debugging purposes.

  5. In the initial boot (the device is has just powered up), the following message should be displayed in the Serial Terminal:

    first_boot_msg

  6. Open a generic BLE mobile application and the Reset Detection device name should be detected, as shown below.

    reset_detection_adv

  7. Connect to the Reset Detection

  8. Once the device is connected to the cell phone, a custom service with two characteristics should be detected. Feel free to read the second characteristic Reset Detection which indicates the reset reason.

    reset_detection_por

  9. Write 0x02 for triggering a Hardfault on the first characteristic Control Point. The device will indicate that a Hardfault will occur and will reset. hardfault_trigger

  10. After the code has reached the hardfault the watchdog will be reloaded and the device will halt in a while(1) loop until the watchdog elapses (provided that the CFG_DEVELOPMENT_DEBUG is undefined). As soon as the watchdog elapses the NMI Handler will occur and the device will SW reset and start executing the ROM booter. If there is no image in the SPI or the memory is not connected to the device the image will have to be downloaded again via Keil, eitherwise the booter will boot using image from the SPI flash. The following message will be printed on the terminal on start up.

    reboot_from_hardfault

    Note: In case the fw is re-downloaded via Keil the debugger will issue a HW reset on the device, this will be identified by the code and a HW reset will be presented as the reason of reset. On the other hand if the image is downloaded from the SPI flash the reset will be identified as a SW reset.

  11. If it is re-connected to the mobile application, the value of the Reset detection characteristic should be 0x0306.

8. Known Limitations

9. License

Copyright (c) 2021 Dialog Semiconductor. All rights reserved.

This software (“Software”) is owned by Dialog Semiconductor. By using this Software you agree that Dialog Semiconductor retains all intellectual property and proprietary rights in and to this Software and any use, reproduction, disclosure or distribution of the Software without express written permission or a license agreement from Dialog Semiconductor is strictly prohibited. This Software is solely for use on or in conjunction with Dialog Semiconductor products.

EXCEPT AS OTHERWISE PROVIDED IN A LICENSE AGREEMENT BETWEEN THE PARTIES OR AS REQUIRED BY LAW, THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. EXCEPT AS OTHERWISE PROVIDED IN A LICENSE AGREEMENT BETWEEN THE PARTIES OR BY LAW, IN NO EVENT SHALL DIALOG SEMICONDUCTOR BE LIABLE FOR ANY DIRECT, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THE SOFTWARE.