How to get system debug using DEBUG_BUILD=y to come out Serial1


Hello again

I’m trying to debug Bluz firmware, having built the system with -DDEBUG_BUILD. On a particle Photon, this results in data spewing out the USB based Serial port. Bluz doesn’t have one of those, so I need to somehow get it going out Serial1 aka the RX/TX pins.

Anyone know how to do this?

EDIT: I found this …

void debug_output_(const char* msg)
    cout << msg << std::endl;

… in core_hal.cpp.

Where to change where cout sends stuff? I’m guessing there must be a definition of putchar() and getch() somewhere … but stuiffed if I can find it … and I’m hoping it’s not that low level, to get what I need.

EDIT: Went on to find #define USE_UART_FOR_STDIO 1 … but that doesn’t seem to achieve anything.

EDIT: Looking through the NRF51 SoftDevice docs, I found this …


… which is supposed set up the USART at 38400 baud and then allow this …

#include "app_trace.h"
  app_trace_log("TESTING!! HELLO?!!!");

… but that does nothing either.

Maybe my USB<–>serial cable is broken? Guess I better test it, just in case. No, it’s fine. (simple echo test).

EDIT: Sanity check …

#include "application.h"

bool ledOn = false;

/* executes once at startup */
void setup() {
    pinMode(D7, OUTPUT);


/* executes continuously after setup() runs */
void loop() {
    if (ledOn) {
        digitalWrite(D7, LOW);
    } else {
        digitalWrite(D7, HIGH);
    ledOn = !ledOn;

{sigh} I give up.


To do debugging, you need to compile like this:


And you need to make sure this line is included in your user app .cpp file:

Serial1DebugOutput debugOutput(38400); // default is 9600 and log everything

I just have an app that is named serial_debug that I know has the proper line. That line needs to go above the setup() and loop() functions, and you don’t need anything else (ie you don’e need Serial.begin or anything)

Then, anywhere in the code (system or user parts) you can just do this:

DEBUG(“Hello from Spark!”);

That will print out to Serial1. Note, however, that there are already a lot of messages hidden around places, so you will start to see a lot of debugging!

Debugging Gateway Shield Firmware

Goodness. Now, why didn’t I figure that out on my own? :stuck_out_tongue:

Thanks @eric!


@eric … As an aside, I have got Segger J-Link Debugger working. Alas, even with the watch dog put to sleep and left to starve, the system just keeps “randomly” ending up in the hard fault handler, before it gets to the stuff I want to debug. (Random as in at various different times, with no apparent pattern.) Happens only when I set a breakpoint.

So, I guess it’s back to Serial1 output and doing it the hard way.


Yeah, unfortunately debugging with the nrf51 is nearly a lost cause. The other issue is that break points hang the CPU, which means the BLE stack stops and all connections drop. This makes it pretty useless to debug most scenarios where you need debugging.

Serial1 is my debugger of choice and has been for a while.


@eric – All I wanted to do was observe whether or not data was copied to the right address, just prior to my breakpoint. It didn’t matter if the system went down after that. But I couldn’t even do that. The addresses looked right, but as soon as memcpy returned, BOOM. Hard fault. LOL (This does NOT occur without any breakpoints set. Useless.)

This has been the case for me for ALL debuggers, on all platforms, since the dawn of time. They may be alright for showing students the inner workings of a CPU. But as soon as you have interrupts or even just a WDT, the show over. Oh well.


I’m frustrated. So, I’m taking a social break.

I’ve spent the better part of three days now, trying to nail this TCPClient crashing problem down. I’m sure it has something to do with crossing the Dynalib thing. But for the life of me, I cannot find it. I’ll keep plugging away though.

Giving Bluz TCPClient via BluzGW -- for Blynk and other things