If you had some very fancy custom firmware, you could deploy binary blobs to your external flash that way. I think the bootloader right now is a bit picky about firmware being loaded over dfu vs. jtag, so you might need to modify your bootloader / makefiles to make sure it’s cool with being loaded via jtag and not dfu.
The core id is literally the etched stm32 id on the processor as a hex string, and you would want to generate a new public/private keypair separate from your previous core.
@BDub, @Dave you were all correct with the incorrect LED wiring. It now flashes YELLOW. It still flashes in bursts whereas the real spark core is a continuous flashing. When I try to use Zadig to install the driver my board only shows up as “Unknown Device” (my real spark core shows up correctly), would this somehow be related to the different flashing rate? would a hardware problem be causing this?Flashing Yellow (in Bursts)
It seems like it might be encountering a watchdog timeout for some reason… and it’s not up and running long enough to show up as a device in Device Manager. It’s hard to tell from your 4 second video what the pattern is… does it repeat the same way forever? Is it flashing really fast like a strobe light for periods of time? It’s really hard to tell. Try covering it up with a piece of paper to help keep the camera focused and at the same white balance. Try this bootloader.bin I have personally programmed my spark core with this one in the past and recovered it from a bricked state.
@BDub, yes it was repeating the same 5 or so rapid flashing, short pause, rapid flashing consistently with no variation. This video is a longer clip. Just tried the bootloader you linked, it gave the correct looking slow continuous flash, however it is still showing up as “Unknown Device”. I have tried a couple different usb ports, deleted the driver I installed with my real spark core with no change.
What was different about the bootloader.bin file you linked? Pretty sure I was using the latest bootloader.bin from GitHub.
This was the first bootloader.bin that Spark uploaded to Github. I believe since then they have changed some stuff in it and added more watchdog timer stuff, and automatic recovery code that helps in the event that you get a bad OTA update. I'm pretty sure the bin I linked doesn't have that stuff, it's dated 1/26/2014 on my computer so you could correlate that with the github commits to find out what was in and what was not in the code.
The flashing slow looks good... you know, the Spark Core that I built I never got it to talk over USB, ever. DFU always failed. But everything in the USB circuitry was connected properly. Back then life was simpler though, just program the bootloader, update the cc3000 and flash your firmware. Now there are keys and ID's and extra stuff, so you'd really probably want DFU mode. It would make life easier. I went back and tried to revive my old spark core v0.2 and for one, the hardware is just old. I didn't have the buffer on the SPI bus, so it's pretty much a museum piece now. Hopefully you started with V1.0 Spark Core schematic.
@BDub, that isn’t very promising if you never got your hand built core to DFU; I started with the latest schematic. @Dave, do you have any idea why the bootloader BDub linked provided a correct looking “DFU Mode Yellow Flash” whereas the latest bootloader.bin provided the rapid burst flashing? (neither were able to DFU) I made up another one of my boards without any of my logic-level conversion and extra stuff (so it should be functionally equivalent to the original core) but that didn’t make any difference…
I think I might try connecting the external flash/LED/MODE button to the Maple Mini I have lying around and flash it with the bootloader to see if I can get that board into DFU mode.
Have you looked at the USB_DISC pin and the associated discrete transistors? These are meant to pull-up USB D+ so that the host knows there is a slave on the line. If that wasn’t working for some reason, that could explain your symptoms. I would certainly look at all those components for possible problems.
If you can lift a resistor (R10 in your schematic above looks likely) and temporarily force the pull-up on (by doing the equivalent of driving USB_DISC low), you might be able to see if that helps.
The flashing in the video was pretty weird. My guess would be some issue with regards to clocking or timing, but I haven’t put one of these together by hand personally, might be a better question for the hardware guys.
@bko, So I tried your advice and looked at the usb transistor stuff. my hand-built version appeared to match what my real Spark Core had as far as voltages go…
USB_DISC == LOW (this was low all the time - even when USB was disconnected)
USBP == 3.3V
USBM == 0.0V
After the simple voltage test I tried it with R10 removed, this didn’t appear to make any difference.
Now to hack my maple mini into a “quasi spark core” for comparison (since I know it connects via USB)
Thanks for checking–sounds like it is something else. You should be able to have a 1.5K pull up on USB D+ all the time for a slave.
One thing Dave said above about the timing triggered a thought: I read a post about a STM32F103 user who was having trouble connecting over USB and it turned out his problem was a badly soldered crystal. Your schematic shows an 8MHz oscillator module, not a crystal like Spark. Is it really a crystal or an oscillator?
So if I am unable to get this board to connect via USB so I can DFU is there any other way to load the necessary files (initially) so I can get it connected (aside from overhauling the bootloader to bypass DFU)? or am I dead in the water?
You crystal datasheet suggests 18pF load capacitance, but your schematic shows 28pF. I’m not sure how critical that will be, but it’s worth a try if you have 18pF caps.
I will order some and give it a try. I think I was going off of CL = (C1*C2)/(C1+C2)+Cstray where I blindly assumed 5pF for Cstray, using 28pF gets a close match (comes out to 19pF)
If it turns out you can’t get usb / dfu working, you can definitely load firmware via jtag, it just requires a few tweaks when building firmware locally. It’s how we used to load code before switching mostly to dfu.
@Dave, does this also apply for the initially loading of keys and the radio driver? (could the .pem & .der file extensions be changed to .bin ,for ST-Link Utility compatibility, without affecting how they are loaded ?)
That’s a good question, the ST-Link / JTag connection will only let you write to the stm32 itself, and not the external flash. To write to the flash you’d need something running on the stm32 (the bootloader, some fancy custom firmware), to catch your binary and write it out. I imagine it wouldn’t be too tough to borrow the OTA flash code and spin up a small TCP server on the core to write things like keys and factory reset binaries to the flash.
Cloud regardless 
