What is output_length before the memcpy()?  Perhaps you're overflowing the output array and overwriting the value of output_length during that memcpy().  The value 13618 is 0x3532 which corresponds to the characters '5' and '2'.

When debugging, I find it useful to single step (the C code, not assembly) up to the line of code causing a crash and watch the variables to ensure that they're valid.  If you did that in your code and saw output_length change after the call to memcpy(), then you'd want to look at the parameters passed to memcpy() to determine how/why you're overflowing your output buffer.

(Also, your pastebin link above has expired.) 

Are you declaring sendbuf on the stack of main(), or as a global?  If it's on the stack, is the stack large enough to hold it?

What's in sendbuf?  Is it a valid, null-terminated JSON string to parse?  What is packer() doing?  I didn't see that function in the cJSON project.

In one of your screenshots, output_length is 13618, and I would guess that output_pointer isn't pointing to an array that large, so this would be a buffer overflow error.  With the Simplicity Studio debugger, you can single step through your program to determine where it's failing to do what you expect it to do.

I know that SiLabs is running some workshops with the BG22 product, and there might be on that walks you through using the debugger of Simplicity Studio.  https://www.silabs.com/wireless/bluetooth/efr32bg22-series-2-socs

I've been using "jsmn" to parse JSON in my project, and it's worked well.  Maybe it's a better choice for embedded than cJSON?  https://github.com/themobiusproject/jsmn

Jason, you should post that as a separate question, instead of an answer to an answered question. 
 

I don’t know which board you’re running, but if you have battery backup it might be possible to go into a low-power sleep mode that just keeps the RTC (real-time clock) running when the main power source goes down. But that won’t survive a hardware reset — you’d need some sort of external battery-backed RTC for that. 
 

In many cases, you can just have your device not know the time/date until it has network connectivity and can acquire that information from an external source. 

I've started exploring the use of presenting a CDC ACM interface on the USB port of a WGM160P board (EFM32GG11).  I based my code on `ex_usbd_cdc_acm_terminal.c` in SSv4.

It's been working well, but I was surprised to see the device appear as a `/dev/tty.usbmodemXXX` on macOS and `/dev/ttyACMx` on Linux instead of `/dev/tty.usbserialXXX` or `/dev/ttyUSBx` (respectively) like an FTDI USB serial adapter.  On the plus side, it's recognized with the built-in `usbser.inf` driver on Windows 10 and appears as a COM port, just like the FTDI adapter.

Since I'm exposing a serial interface and am not actually a modem (and don't accept AT commands), is there any way to tweak my CDC/ACM configuration to appear as a `tty.usbserialXXX` or `ttyUSBx` device on those operating systems?

I tried changing from `USBD_CDC_COMM_PROTOCOL_AT_V250` to `USBD_CDC_COMM_PROTOCOL_NONE`, and even trying alternate values passed to `USBD_ACM_SerialAdd()`, but to no avail.

I'm still looking into whether it actually matters on macOS and Linux.  As of yet, I've only run into a problem with a system that wasn't expecting the `/dev/ttyACMx` device name, but it should be possible to update it to check both `/dev/ttyUSBx` and `/dev/ttyACMx`.

When we had a similar need, we ended up using the SRecord utility.  http://srecord.sourceforge.net

It can convert a .bin file to a .s37 with an offset, and has the ability to combine multiple files into a single hex file for programming.

A project I worked on that used IAR Embedded Workbench made use of Cpputest (http://cpputest.github.io) to test portions of the project.

It required creating "mocks" for a lot of the Gecko SDK code, but it was possible to test functions in individual .C files to ensure that certain inputs resulted in specific outputs.

It gets much more complicated when you're trying to unit tests a program with communication between tasks, but it is good to validate logic in many of the support functions you'll end up writing.  If you organize your files well, you can put most of the logic into testable functions/files that don't require much more than the Standard C Library.  That leaves simple hardware-specific or RTOS-specific code with minimal logic to test/validate.

Or, mock the hardware/RTOS calls to essentially be no-ops where you configure the return values in the test setup.

All of this runs from gcc on the command-line in the development environment, or on whatever you might use as your CI (continuous integration) platform.

Olivier,

Yep, I'm pretty sure I neglected to read through that part of the manual when I explored what was possible on that interface.  I came across this section after the fact, and have confirmed that I can't power the module on its own with the USB interface.

"With the WGM160P radio board, the USB position of the power switch is disconnected. Instead, a transistor switch on the radio board itself connects the on-board regulator to the module power supply when the target USB cable is inserted. Please note that this happens regardless of the power switch position, so the power switch should be set to USB or BAT when using the radio board USB connector to avoid conflict. The transistor switch allows the radio board to be powered by a USB cable even when removed from the WSTK main- board."

I'm fairly certain that as a result I damaged the regulator or one of its support components.  A nice modification to the board would be to disable U100 if the BRD4321A is receiving power from P200 or P201.

Olivier,

Yep, I'm pretty sure I neglected to read through that part of the manual when I explored what was possible on that interface.  I came across this section after the fact, and have confirmed that I can't power the module on its own with the USB interface.

"With the WGM160P radio board, the USB position of the power switch is disconnected. Instead, a transistor switch on the radio board itself connects the on-board regulator to the module power supply when the target USB cable is inserted. Please note that this happens regardless of the power switch position, so the power switch should be set to USB or BAT when using the radio board USB connector to avoid conflict. The transistor switch allows the radio board to be powered by a USB cable even when removed from the WSTK main- board."

I'm fairly certain that as a result I damaged the regulator or one of its support components.  A nice modification to the board would be to disable U100 if the BRD4321A is receiving power from P200 or P201.

Update: I decided to remove U100 from the board, which would ensure the USB interface doesn't compete with the baseboard to provide power.  My snips weren't precise enough to cut the pins, but a razor blade worked to cut the pins between the chip and solder pads.

Olivier,

Yep, I'm pretty sure I neglected to read through that part of the manual when I explored what was possible on that interface.  I came across this section after the fact, and have confirmed that I can't power the module on its own with the USB interface.

"With the WGM160P radio board, the USB position of the power switch is disconnected. Instead, a transistor switch on the radio board itself connects the on-board regulator to the module power supply when the target USB cable is inserted. Please note that this happens regardless of the power switch position, so the power switch should be set to USB or BAT when using the radio board USB connector to avoid conflict. The transistor switch allows the radio board to be powered by a USB cable even when removed from the WSTK main- board."

I'm fairly certain that as a result I damaged the regulator or one of its support components.  A nice modification to the board would be to disable U100 if the BRD4321A is receiving power from P200 or P201.

Update: I decided to remove the damaged U100 from the board, which would ensure the USB interface doesn't compete with the baseboard to provide power.  My snips weren't precise enough to cut the pins, but a razor blade worked to cut the pins between the chip and solder pads.  I'll be more careful with future boards to ensure that I can power them via the USB port when not connected to the baseboard.