Advanced SWO debugging advice

Hi Ian, We do development on the device using one of the EFM32 starter kits as an external debugger as these are nicely integrated with the Simplicity Studio tools.

The uMoth uses the same EFM32WG micro-controller as the AudioMoth so it will run all the same firmware and is electrically equivalent. It has the same GPIO pins so external devices such as GPS modules can be connected. Alex

May I please enquire which board you folks are checking your firmware with? EFM32WG-DK3850?

The uMoth has piqued my interest. Is the wonder gecko chip still planed to be used for the new board?Any chance there are some pins there to extend the device?

Thanks :)

That sounds great. Other than the existing team and a few of my undergraduate project students we haven't had much outside development so it would be great to see more of this. One of my recent students made nice build environment for the AudioMoth project that doesn't require Simplicity Studio - https://github.com/david-perez/AudioMoth-Project.

I’ll try the Logfile approach first and then fallback to the EFM32 debug boards if it’s still going sideways.

I have implemented some unit testing via Unity within my firmware. It has provided additional assurance that the USB changes which are being made are correctly defined. The idea to extend the project with a test harness is an interesting concept. I've also briefly attempted a C++ port of the firmware to assist abstraction and isolation for similar reasons, providing a test surface, removed from interrupts and EM4 woes. If this goes anywhere positive I’ll let the community know.

Hi, We typically debug directly on the hardware except when experimenting with digital signal processing where we can test initial versions offline, and to test functions such as -

scheduleRecording(uint32_t currentTime, uint32_t *timeOfNextRecording, uint32_t *durationOfNextRecording)

- which don't involve any actual hardware interaction.

One really useful thing to develop would be an AudioMoth simulator which would simulate the library calls and generate the appropriate interrupts such that all of the application code could be tested offline. We haven't done that but it would be an interesting project.

We typically use one of the EFM32 starter kits as an external debugger as they are cheap and are well integrated with the Simplicity Studio environment. All this requires is the addition of the AudioMoth_setupSWOForPrint function to the setup routine (as you have in your example) and then the SWO outputs appear in the console output when running the debugger within Simplicity Studio. You can then also set breakpoints and explore the SRAM and flash contents.

The one challenge with this approach is that the standard AudioMoth code goes into EM4 mode and is woken by the BURTC every couple of seconds and doing so will cause the debugger to lose connection.

Writing the activity of the device to the SD card is also really useful and is what we typically do for custom versions of firmware so we can log anything we like over extended periods of time. We generally add a macro:

#define RETURN_ON_FALSE(fn) { \

bool success = (fn); \

if (!success) return; \

}

and then use a logging function:

void writeLog(uint32_t currentTime, char *message) {

if (!fileSystemEnabled) fileSystemEnabled = AudioMoth_enableFileSystem();

if (!fileSystemEnabled) return;

RETURN_ON_FALSE(AudioMoth_appendFile(logFilename));

struct tm *time = gmtime((time_t*)&currentTime);

sprintf(logBuffer, "%02d/%02d/%04d %02d:%02d:%02d: ", time->tm_mday, time->tm_mon + 1, time->tm_year + 1900, time->tm_hour, time->tm_min, time->tm_sec);

RETURN_ON_FALSE(AudioMoth_writeToFile(logBuffer, strnlen(logBuffer, LOG_BUFFER_LENGTH)));

RETURN_ON_FALSE(AudioMoth_writeToFile(message, strlen(message)));

RETURN_ON_FALSE(AudioMoth_writeToFile("\n", 1));

RETURN_ON_FALSE(AudioMoth_closeFile());

}