Opps sorry. When i mean handshaking, it’s not literally the handshaking code only.
There are a couple of messages send between the core and cloud so it will be nice to know which is causing the failure. 
I have no idea which OSx version is it running but probably the latest.
Right. Well the problem I have is not knowing how to get debug information out of the firmware side of things. I can change the code, like I did to insert delays. But how can I get debug information reported?
I do have a JTAG interface and can sort of use gdb. But I have no clue how to use that to debug code outside the core-firmware/src folder – not to mention how to handle interrupts and whatnot. I’m a real junior at gdb, having hardly ever used it. I have always found debuggers awkward and very difficult to manage. All my real life, useful debugging, over 20+ years of embedded MCU work (play? :-P) has been using serial ports or LCD displays and code editing.
EDIT: Perhaps I can figure out how to send serial data out the TX pin?
#include "application.h"
#include "spark_disable_wlan.h"
#include "spark_disable_cloud.h"
void setup() {
pinMode(D7,OUTPUT);
digitalWrite(D7, LOW);
Spark.disconnect();
WiFi.off();
delay(2000);
WiFi.on();
delay(2000);
Spark.connect();
}
void loop() {
//Indicates user loop running
digitalWrite(D7, HIGH);
delay(100);
digitalWrite(D7, LOW);
delay(100);
}
Please compile using the current Web IDE instead 
@kennethlimcp … incidentally, you can compile locally on my system, too. That was my main idea, for remote access, I guess. The firmware is in ~/sparkcore/.
If you like, I could connect the JTAG interface as well.
How can I do that, on a local server? :-/
erm… Download here: https://dl.dropboxusercontent.com/u/36134145/firmware.bin
1.) you can actually paste the code in the WEB IDE and download the binary file
2.) The spark-cli can do spark compile code_name.ino as well.
Oh. Wow. I didn’t know either of those little facts.
OK, will do. In the meantime, I just compiled the code you posted above locally and it’s running. The 'core is breathing green and the user loop D7 LED is flashing as expected. Multiple resets all provide the exact same behaviour.
OK. I flashed that .bin file to the core and (not surprisingly) it's behaving just the same as the local compiled, reported previous post.
I see there’s a bunch of DEBUG(...) calls in the firmware source. I’m now working to see what those do. Send data out the serial port, perhaps? I can work with that. I’ll get back soon with results during failed handshake.
Ok i have modified the code slightly to connect to the cloud. Can you compile again and try?
You should see it having SOS every time Spark.connected(). I’m starting to get suspicious of firmware…
The moment i factory reset, the factory reset tinker gets loaded in the core and everything runs fine. However, flashing the new tinker firmware in the spark-cli gives me SOS flashes which shouldn’t be the case.
I’m suspecting that the cc3000_patch_version broadcast might be messing things up…
AH HA! Version 0.20 stock tinker firmware did not give me any issues…
@gruvin, can you download this https://github.com/spark/core-firmware/releases/tag/spark_3 and flash the core-firmware.bin in the build folder and observe what happens?
Also, try this: https://github.com/spark/spark-cli/blob/10f65d1eba553df807457a5b90388704ea14b2bf/js/binaries/spark_tinker.bin
It seems like some code in the new firmware version is causing issues?
It works! Multiple resets and no issues at all connecting to local cloud. 
Same again. The problem completely gone away.
Good spotting! This is certainly the closest we've come to finding the problem.
YAHOOOOOOOOOOOOOOOO! 
Like i mentioned, it should most likely be the cc3000_patch_version publishing but i might be wrong.
Meanwhile, I have finally figured out how to get the DEBUG reporting from the core firmware working. I have it sending data out the TX pin at 9600 baud. Unfortunately though, there’s been a recent issue with that as well, where the 'core only breaths green after reset and doesn’t connect to any server – if in DEBUG mode. Shiucks! (See here.) So until that issue is resolved, I cannot get the debug info for this handshake issue.
my 2$ if anyone wants to put debug output over serial, add this code:
static bool log = false;
void debug_output_(const char *p)
{
if (log)
Serial.println(p);
}
And then in setup()
Serial.begin(57600);
log = true;
oh no. We wanted to see the DEBUG in the firmware itself and not our own code.
Can we try to uncomment this:
This is for DEBUG in firmware. All debug output goes to the debug_output_ functon. Most forward this to serial1, but here I forward to regular serial, so you don’t need any additional hardware.
It’s best to change the output level LOG_LEVEL_AT_RUN_TIME in debug.h since there is a lot of it!
opps sorry. 
I have not forced myself to work in a local compile environment but it seems like i need to do it soon. 
What @mdma said was correct, though. The DEBUG macro requires us to define the debug_output_() function ourselves, so that it can send the debug info somewhere.
That doesn't get past the, "stuck at breathing green" issue, noted here, unfortunately.
Do you also happen to know how to get around the recent problem of the 'core not continuing on to connect to the cloud, when make DEBUG_BUILD=y is used? It's reported here.
If you do know the answer to that, then that other thread would be the place to share it. Thanks
Meanwhile, for what it's worth here, following is the entirety of debug output I am seeing, before the 'core just breaths green and goes no further ...
0000000001:<DEBUG> int main() (159):Hello from Spark!
0000000466:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001381:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001382:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001448:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001449:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001450:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001451:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001517:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001518:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001519:<WARN > SpiWrite (334):CC3000 SpiWrite acquire bus
0000001584:<WARN > SPI_DMA_IntHandler (437):CC3000 DmaHandler release write spi bus
0000001585:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001586:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
0000001587:<ERROR> hci_event_handler (555):type != HCI_TYPE_EVNT is (2) usRxDataPending=0 usRxEventOpcode=513 usReceivedEventOpcode=0
0000002236:<WARN > SPI_DMA_IntHandler (408):CC3000 DmaHandler release read spi bus
I've tried adding a Spark.connect(); manually, in setup(). But it does nothing.
EDIT: The <ERROR> above is produced at core-common-lib/CC3000_Host_Driver/evnt_handler.c" line 551 ...
if (*pucReceivedData == HCI_TYPE_EVNT)
{
...
}
else
{
if (tSLInformation.usRxDataPending == 0)
{
ERROR("type != HCI_TYPE_EVNT is (%d) usRxDataPending=%d usRxEventOpcode=%u usReceivedEventOpcode=%u",
*pucReceivedData,
tSLInformation.usRxDataPending,
tSLInformation.usRxEventOpcode,
usReceivedEventOpcode);
}
else
{ ...
EDIT2: Potential goose chase comments removed.
I think I had the cloud disabled for the debug code I was using, it’s late here, but I’ll try to take a look tomorrow with cloud enabled. But I do see there’s something not right - changing the debug level from DEBUG to WARN caused the device not to be recognized in windows. I just dismissed it, but given more time I’d like to investigate.