Handbuilt Core- Rapid Flashing after loading Bootloader

Just a quick thought… if you erase the STM32 and program the bootloader only, the LED should blink YELLOW. I don’t even see any code that would make it blink CYAN https://github.com/spark/bootloader/blob/master/src/main.c There are some other colors that it could blink, but not likely by default right after programming a blank chip. I would track this down before trying to debug anything else, and it just complicates the process. You won’t be able to rely on the debugging status of the LED to tell you what mode the Spark thinks it’s in.

My internet is being super slow right now so I can’t find where the LED pins are defined in the bootloader. Or where hw_config.h is.

boom! https://github.com/spark/core-common-lib/blob/master/SPARK_Firmware_Driver/inc/hw_config.h

My hunch, like @BDub, is that the LED is wired differently. I’d be willing to bet that DFU mode = yellow (red + green) on a :spark: Core = cyan (blue + green) on your hand-built Core. The way to check this is with dfu-util -l as @Dave said.

If you erase the STM32 and install only the bootloader at 0x08000000 with no firmware installed, then it should just boot up into DFU mode because there’s no firmware to run.

Oh that was driving me nuts… I was thinking the Bootloader was self contained… but I forgot about the common lib.


Another step is to make sure the CORE DFU driver is installed. If the Core is blinking YELLOW (or CYAN if messed up somehow) and is in DFU mode, the Core will show up in the Device Manager with the CORE DFU driver. I’m guessing you have real Spark Core’s and have already done this on your target computer?

What does the dfu-util -l report? Also assuming you have used this before on the target computer with success. Try it with a real Core if you have one and make sure it’s all working… using the same cable.

1 Like

@BDub I finally I see the wiring mistake… I kept comparing the LED# labels to the STM32 pin numbers which of course match, I don’t remember my thought process when wiring to the LED itself (too many projects going on at once). For sanity I am going to pop off the LED tonight and wire it the way it should so I can see the correct colors…

I was able to connect my real Spark Core last night and it did in fact show up as CORE DFU, so hopefully I can get my goofed up board to do the same (I did connect it last night and try but wasn’t very thorough since I was barely functioning at that point).

@BDub, how do you determine the core ID, Spark CLI or is there another way?

On the note of DFU mode, this board ultimately doesn’t need a USB connection aside from the initial programming… is there a way to flash all the necessary code (to include keys, CC3000 Patch, Firmware) using JTAG alone? I tried this with my first version that doesn’t have USB but noticed the ST-LINK utility doesn’t support *.pem *.der extensions

You can put it into listening mode and request the ID over Serial USB by pressing the i key. I guess this is more or less the same as the Spark CLI though.
http://docs.spark.io/#/connect/connecting-your-core-connect-over-usb

However you probably have to get your PUBLIC KEY and ID sorted with @Dave first. But

Yep, you can flash the Bootloader.bin to address 0x8000000 and the Core-firmware.bin to 0x8005000. I’m not sure if you can get the Factory-firmware.bin and Public Key programmed to external Flash though through the ST-Link though. I’ve only done this over DFU USB. Check out the process here:

I’m guessing you need DFU for the external Flash since that flash is on the STM32’s SPI bus. That said, you can write the data from a core-firmware.bin file much like you’ll do for the cc3000_patch_firmware.bin so I’d say it’s possible to do it all via JTAG and letting the code run.

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.

Thanks!
David

3 Likes

@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)

Unknown device sounds like a driver issue most of the time but since your other core is showing up correctly, it has to be something else then!

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.

Windows device manager shows Code 43 error.

On my mac-mini, dfu-util -l gives (sometimes)
Found Runtime: [05ac:828a] devnum=0, cfg=1, intf=3, alt=0, name=“UNDEFINED”

(not sure what that is/means, only additional stuff plugged into mac are two receivers (keyboard/mouse))

That is the built-in Apple bluetooth chip, I believe.

1 Like

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.

It’s ok, because I got it connected to the :spark: Cloud regardless :wink:

Hi @jwalker

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. :slight_smile:

@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?

Just another random thought.

1 Like