Hi,
How do i enable this line of code:
DEBUG(“Hello from Spark!”); in file main.cpp
My setup is:
programming over usb through DFU + Netbeans
spark connected over usb
windows comm driver installed
usbserial included in application.cpp
Serial.begin(57600) etc…
Serial1.begin(57600) works fine through ttl->USB convertor
If anyone knows? thanks!
This is a great question for @david_s5
It looks like you will have to at least un-define USE_ONLY_PANIC but I didn’t see how the serial port gets connected
That is defined in
core-common-lib/SPARK_Firmware_Driver/inc/config.h
Get ready for your flash size to go way up since all the debug prints get enabled!
Hi,
You do have to undef USE_ONLY_PANIC and define DEBUG_BUILD
The application (core) all the libs need to be built this way - I would suggest a local build or ask @Dave if there is a way to do this in the web IDE
Then pick the output device…
void debug_output_(const char *p)
{
static boolean once = false;
if (!once)
{
once = true;
Serial1.begin(115200);
}
Serial1.print(p);
}
Then these will work.
DEBUG("Test TCP BAD Every %d Usage!",bad_every);
LOG("The following 4 mmessages are a test of the logger....");
LOG("Want %d more cores",command_i);
WARN("Running %s on cores only %d more left","Low",command_i);
DEBUG("connection closed %d",command_i);
ERROR("Flash write Failed @0x%0x",command_i);
LOG("Logger test Done");
PANIC(42,"Can I have a ride!")
Thank’s, it’s a clear answer!
thanks, I get it now!
(cc @david_s5) It appears that some of these areas have changed, and my debugging no longer works using the hook into main.cpp (the debug_output_ method) and running “make DEBUG_BUILD=y”
I know get a breathing green and the following log output (so it’s logging, but gets stuck):
0000000565: SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001496: SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001497: SpiWrite (334):CC3000 SpiWrite acquire bus
0000001497: SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001612: SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
000000161dler release read spi bus
0000001618: hci_event_handler (555):type != HCI_TYPE_EVNT is (2) usRxDataPending=0 usRxEventOpcode=513 usReceivedEventOpcode=0
0000001750: SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000002419: SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
This no longer appears to work. I replied above with the error output that results from building DEBUG_BUILD=y.
I should be clear, the method works, but the act of building debug causes an error (that DOES log :)).
Just to be sure: you did undef USE_ONLY_PANIC again, right?
Well, I’ve tried that yes. However, it wasn’t necessary the first time, or this time…logging IS working. I’ll try to explain. 
Undefing USE_ONLY_PANIC wasn’t necessary if you build with DEBUG_BUILD=y because USE_ONLY_PANIC would never get defined, which makes sense and how it should be. In order to enjoy the wonderful debugging, all that was necessary was adding the function to main.cpp that setup and send log data to Serial. Minor editing, big win!
Since pulling in the latest firmware changes, if I build with DEBUG_BUILD=y the Spark Core goes into the green breathing state, and logs the following (so you see, its logging, and not just ERROR but also WARN):
0000000565:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001496:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001497:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001497:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
00000016n2ler (408):CC3000 DmaHandler release read spi bus
0000001613:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001614:<WARN > SPI_DMA_IntHandler (437):CC30ite spi bus
0000001616:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001617:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001618:<ERROR> hci_event_handler (555):type != HCI_TYPE_EVNT is (2) usRxDataPending=0 usRxEventOpcode=513 usReceivedEventOpcode=0
0000001744:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000002161:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
So, logging still works, but something about having the special logging function in main.cpp is causing the above error.
If I remove the following from main.cpp, the core will launch just fine, but I can no longer see logging:
#ifdef DEBUG_BUILD
void debug_output_(const char *p)
{
static boolean once = false;
if (!once) {
once = true;
Serial.begin(19200);
}
Serial.print(p);
}
#endif
So why does this function now cause the above error? That is the mystery. 
This error is coming from the CC3000_Host_Driver/evnt_handler.c and means that we got a return code that should have meant RX data was available, but the message said there was no data pending. It seems benign.
Could this be an artifact of the before-and-after a deep update?
Unfortunately not benign enough, as I’m stuck in green breathing, unable to run any code. 
I personally don’t know enough about the deep update changes to give any input there. It definitely isn’t the result of me running a deep update, however.
OK, sorry–didn’t realize it was stuck for you.
@satishgn made a change in that area of the driver in April, upgrading from the TI source. Maybe he can comment.
No worries @bko! Glad to have your insight to help figure this out.
Me too. 
Checking in so I get notifications, when you find a solution! 
Thanks.
It would seem that the short delays introduced by our debug output is what it causing this ‘stuck at breathing green’ issue. When I set the log level to ERROR in debug.h, which prevents all the WARNS etc, then the system works again.
#if defined(DEBUG_BUILD)
#define LOG_LEVEL_AT_COMPILE_TIME ERROR_LEVEL
#define LOG_LEVEL_AT_RUN_TIME ERROR_LEVEL
#endif
I might try going back to DEBUG_LEVEL, but try to disable WARN elsewhere, so as to cause much less delay from the WARN message but hopefully still see DEBUG level messages.
Seems like it’s fixed here:
For those compiling locally…maybe this should help?
That fixes it! Zachary is amazing. I was in touch with him yesterday about the issue and he took care of it. That, my friends, is some major support. I’m no longer stuck!
This raises a good point. I think the Dev team should not release code for general release the has debugging message added that can affect operations or timing.
One can remove the test code or add overrides per module with macros so they are benign
#define MODULE_DEBUG
#if defined(MODULE_DEBUG)
#define DEV_WARN(fmt,...) WARN(fmt,##__VA_ARGS__)
#define DEV_ERROR(fmt,...) ERROR(fmt,##__VA_ARGS__)
#else
#define DEV_WARN(fmt,...)
#define DEV_ERROR(fmt,...)
#endif
Does this means that i can simply use the local compile (gcc via MAKE) to enable the DEBUG printing over Serial?
I’m going to dive deeper into some firmware bugs and using DEBUG is going to be better than adding my own Serial.print everywhere i need to 
Is there a different approach taken other than Serial.print()?
I tried this in main.cpp but didn’t worked
include "application.h"
#undef USE_ONLY_PANIC
#define DEBUG_BUILD
#ifdef DEBUG_BUILD
void debug_output_(const char *p)
{
static boolean once = false;
if (!once) {
once = true;
Serial.begin(9600);
}
Serial.print(p);
}
#endif
Hi,
Good news, but does it help the following issue:
I use the on board flash as a storage device (for my SFS, as you might recall) and every now and than the reading of the flash chip creates a major hang of my application.
During this situation the rgb led continues to do whatever is suitable; ergo the main loop is still running, if I’m correct. And a blink I implemented in the loop() function of D7 continues as well.The data retrieval functions ( based on the core functions of course) just return with nothing…
any thoughts?