Slow (damaged?) Spark Core

Troubleshooting
1

I have a Spark that I think I might have damaged soldering into a carrier PCB. The core seems to be running REALLY slow. When you first power it up, it flashes white for a number of seconds. I think the white flash (and all the LED flashes) are actually the firmware modulating the LED.

I can get it into Yellow Flash DFU mode, but the device is not recognised. I have tried a Factory Reset, but that did not help either. And it is not appearing as a serial port on the USB either.

I am just wondering what I should do, and what the issue is? Have I somehow fried the firmware - where uploading it again with JTAG might help

Thanks

Darryl

2

Is it a brand new core?

The breathing white symptom means communicating with the CC3000 and it might be related to a soldering issue for the pads.

However, we have yet to pinpoint a reliable solution to resolve this issue.

If you put it in a slightly warmer area, it should behave normally. For a new core, we can arrange for a replacement :slight_smile:

Update

If you soldered the core then…

3

Yes... Brand new, apart from being soldered in. It was working before I soldered it in. Of the 10 units I soldered in, this was the only one that had this issue.

I have desoldered, and it still has the same issue. I just put the CRO on the 8 MHz crystal, and one of the pins is high, and the other is low, suggesting it is not oscillating. On a working Core, the crystal is running at the 8 MHz. But it could be that the 8 MHz is not supposed to be running in whatever mode the device is running in at the moment. The 32 kHz clock is also not running, but the signal can clearly be seen on the working unit.

I am not familiar enough on how the setup is done... I can try most things - I have a logic analyser and a scope if that helps...

Darryl

1 Like
4

I have no clue but since it was working before… the heat might have caused some issues and I usually don’t recommend soldering directly…

We just have to figure out what is burnt…

5

I have just looked at the STM32 manual, and found the following:

System clock selection is performed on startup, however the internal RC 8 MHz oscillator is
selected as default CPU clock on reset. An external 4-16 MHz clock can be selected, in
which case it is monitored for failure. If failure is detected, the system automatically switches
back to the internal RC oscillator

This sort of lines up with what I am seeing, but I would expect the device to be running slower. Sounds like it is time to grab a JTAG interface... I will add a BUS PIRATE with my next order from SEEED STUDIOS.

It also sounds like I should be more careful with soldering, and with antistatic procedures. To be honest, I can life with a small failure rate, at least at the moment.

Darryl

2 Likes