| BlueNRG-1 BLE Applications

Debugging Tips & Main Guidelines

This document provides some useful debugging guidelines to be followed when debugging BLE applications, programming BLE applications using ST-Link tool and how to use the crash handler utilities

# Debug a BlueNRG-1 BLE application

## Debug vs BLE radio operations

- BlueNRG-1 BLE radio operations are driven by the radio timer ISR:
  - Every time the radio ISR is called, in order to maintain the synchronization with the connection event, the next timeout is programmed with the new value according the actual value.
  - BlueNRG-1 is a SOC with BLE radio: if the execution is stopped for debug purpose, this will imply some delay on the radio ISR management which could lead to connection lost and bad radio behaviour:
    - i.e.: if the application stops the code execution, the synchronization can’t be maintained and the connection can be lost;
    - i.e.: if the application stops the code execution, in case of advertising a back to back communication can be started.
  - As consequence, when debugging a BLE application, please take in account that radio communication can be compromised and the connection can be lost

## Debug vs BlueNRG-1 low power modes

- When the BlueNRG-1 device is in sleep mode (BlueNRG_Sleep() API configured with sleep mode SLEEPMODE_WAKETIMER or SLEEPMODE_NOTIMER), the JTAG/SWD pins are disabled:
  - During debugging section, user should use SLEEPMODE_CPU_HALT sleep mode parameter on BlueNRG_Sleep() API.

## BlueNRG-1 low power modes vs ST-Link tool

- When the BlueNRG-1 device is in sleep mode (BlueNRG_Sleep() API configured with sleep mode SLEEPMODE_WAKETIMER or SLEEPMODE_NOTIMER), the JTAG/SWD pins are disabled:
  - In order to use ST_link tool to programm the BlueNRG-1 device from a IDE (i.e. EWARM IAR) user could follow some tips:
    - Add some delay at the beginning (i.e. on main() function add Clock_Init() followed by a delay of 2 seconds: Clock_Wait(2000)):
      - Reset the BlueNRG-1 and run the flash procedure from selected IDE IAR in a time of 2 sec.
    - Put the IO7 pin high and then reset the BlueNRG-1 device: UART bootloader is activated and user can programm the selected application (with SLEEPMODE_CPU_HALT sleep mode parameter).
    - Perform a mass erase of the device using the BlueNRG-1 Flasher tool (which uses the BlueNRG-1 UART bootloader) and the program the selected application (with SLEEPMODE_CPU_HALT sleep mode parameter)

# BlueNRG-1 Crash Handler utilities

- Some crash handler utilities/structures are provided on BlueNRG-1 DK SW package framework: \Library\hal\inc\crash_handler.h file:
  - crash_info_t structure: it defines the overall crash information structure(stack pointer, programm counter, registers, ...).
  - GET_CRASH_INFO(crash_info): it allows to get the crash information on variable crash_info (crash_info_t crash_info).
  - CRASH_HANDLER(signature): it is a macro which allows to store on variable crash_info the crash information related to a specific type (signature: ASSERT_SIGNATURE, NMI_SIGNATURE, HARD_FAULT_SIGNATURE, WATCHDOG_SIGNATURE).
  - ASSERT_HANDLER(expression): it is a macro which allows to store in RAM the register information where an assert is verified.

## BlueNRG-1 Crash Handler utilities: basic example

Figure 1: BlueNRG-1 crash handler basic example

- Figure 1 shows the main application of a BlueNRG-1 BLE applicaton Sensor application using the crash handler utilities: CRASH_HANDLER() macro
  - crash_info variable defines the variable where crash info information are stored
  - GET_CRASH_INFO(crash_info) allows to eanable the crash information storage
  - At reset, if an assert occurs, application will detect it (if (crash_info.crash_info.signature&0xFFFF0000) == ASSERT_SIGNATURE))
  - By analyzing the crash_info data (registers, stack pointer, programm counter value), user can get some useful information in order to identify issue root cause.

## BlueNRG-1 Crash Handler utilities: basic example

Figure 2: BlueNRG-1 crash handler NMI and Hard Fault handler information storage

- Figure 2 shows the usage of the CRASH_HANDLER() macro in order to store NMI and Hard Fault exception crash information on related interrupt handlers:
  - CRASH_HANDLER(NMI_SIGNATURE) on BlueNRG-1 NMI_Handler() irq handler;
  - CRASH_HANDLER(HARD_FAULT_SIGNATURE) on BlueNRG-1 NMI HardFault_Handler() irq handler;

# References

- Refer to BlueNRG-1 HAL drivers APIs doxygen documentation, crash_handler.h file for crash handler structures, utilities details.