top of page

Support Forum

Public·1086 members

Advanced SWO debugging advice

Hi,


I'm attempting to modify the basic firmware, and I'm progressing quite well however there are a couple of sneaky scenarios which require a lower level debugging capability.


Can you please advise how you debug the firmware, on the device?


I've modified the firmware to call 'AudioMoth_setupSWOForPrint' at the end of AudioMoth_initialise() and added a couple of debug statements such as printf("Debugging enabled"); Throughout the code, being executed. These changes, along with my other alterations were then successfully flashed to the AudioMoth device.


I've then connected my J-Link debug probe https://www.segger.com/products/debug-probes/j-link/, which appears to support the EFM32WG980F256 chip. https://www.segger.com/downloads/supported-devices.php


1. PC -> USB -> AudioMoth USB plug (normal USB connection for an AudioMoth)

2. PC -> USB -> JLink Debug Probe -> SWD via Dupont Connectors -> AudioMoth Debug pads

Here's a couple of photos to highlight what I'm doing. Sure, those connections are soldered a little rough but have been verified to be fine.





As a simple dump, here's what I'm using. I'm expecting you're doing something similar when modifying the firmware.

JLinkExe
SEGGER J-Link Commander V6.52c (Compiled Oct 11 2019 15:44:58)
DLL version V6.52c, compiled Oct 11 2019 15:44:50

....

Type "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: EFM32WG980F256
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "EFM32WG980F256" selected.

Connecting to target via SWD
Found SW-DP with ID 0x2BA01477
Scanning AP map to find all available APs
AP[1]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
Iterating through AP map to find AHB-AP to use
AP[0]: Core found
AP[0]: AHB-AP ROM base: 0xE00FF000
CPUID register: 0x410FC241. Implementer code: 0x41 (ARM)
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl[0] @ E00FF000
ROMTbl[0][0]: E000E000, CID: B105E00D, PID: 000BB00C SCS-M7
ROMTbl[0][1]: E0001000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl[0][2]: E0002000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl[0][3]: E0000000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl[0][4]: E0040000, CID: B105900D, PID: 003BB923 TPIU-Lite
ROMTbl[0][5]: E0041000, CID: B105900D, PID: 000BB925 ETM
Cortex-M4 identified.
J-Link>SWORead
0 bytes read (0 bytes in host buffer)
J-Link>SWOView

Receiving SWO data @ 4000 kHz.
Data from stimulus port 0:
-----------------------------------------------

Occasionally I'll get SWO output, but its all garbled and meaningless. On other hardware I would think this was a mismatch of the receiving clock (4000 kHz), but maybe I'm attacking this incorrectly.


I appreciate this is getting down into the lower levels of core programming on the device but I suspect other users may wish to also understand these debugging aspects when modifying the firmware to suit their needs also. Without a device level debugging capability the only way to check out changes is to flash the device with extra LED flashes to highlight state changes, or log to the microSD via the AudioMoth_appendFile operation.


Which SWO debug probe do you use to validate changes to the base firmware?

What code changes do you make to enable debugging?

Are there Simplicity Studio changes which you utilise to support debugging on the device?

Are you debugging the code off the device instead, on a PC using a 32-bit ARM emulator or 32-bit x86 target toolchain?

Are you implementing Unit Testing on your version of the firmware?

736 Views
Alex Rogers
Alex Rogers
25. Juni 2020

Hi, Yes, when the AudioMoth enters EM4 the debugger will disconnect making logging difficult. You can either write a log file to the SD card in these case, or use the UART on the GPIO to transmit debugging information. If you are using AudioMoth 1.1.0 the file below will do this. Alex #include <stdint.h>

#include <stdbool.h>


#include "em_cmu.h"

#include "em_gpio.h"

#include "em_usart.h"

#include "logger.h"


#define TX_PIN 9

#define UART_TX_GPIOPORT gpioPortB

/* Enable logger output */

void Logger_enable() { /* Pull output pin high */ GPIO_PinModeSet(UART_TX_GPIOPORT, TX_PIN, gpioModePushPull, 1);

/* Enable clock */

CMU_ClockEnable(cmuClock_UART1, true);

/* Initialise interface */

USART_InitAsync_TypeDef uartInit = USART_INITASYNC_DEFAULT;

uartInit.enable = usartDisable;

uartInit.baudrate = 9600;

USART_InitAsync(UART1, &uartInit);

/* Enable route */

UART1->ROUTE = UART_ROUTE_TXPEN | UART_ROUTE_LOCATION_LOC2;

/* Enable UART */

USART_Enable(UART1, usartEnableTx);

}


/* Send logger output */


void Logger_sendBytes(char *bytes, uint32_t length) {

for (uint8_t i = 0; i < length; i += 1) {

uint8_t byte = bytes[i];

USART_Tx(UART1, byte);

}

}


/* Disable logger output */

void Logger_disable() {

GPIO_PinModeSet(UART_TX_GPIOPORT, TX_PIN, gpioModeDisabled, 0);

CMU_ClockEnable(cmuClock_UART1, false);

USART_Reset(UART1);

}

Support Forum

©2026 Open Acoustic Devices

bottom of page