My SparkCore falls back to DFU mode after every Flash from the cloud

Troubleshooting
1

Hi.

Everytime I flash new firmware to my Spark Core, it flashes magenta and goes to the usual routine, but then when it resets it goes into DFU mode!. This happens of course without touching anything.

I download the bin and flash it directly using dfu-util and everything works fine. Except if I try to flash it again from the cloud! It goes again into DFU mode.

I tried factory reset, new firmware install using dfu-util, etc, etc, etc… Any ideas? Is this a boot loader problem?

UPDATE: It does this no matter what code I flash to it. I tried several proven firmwares I wrote that run smooth on other devices.

2

sounds like the yellow flash flash of death… maybe?? search ‘yellow flash’ there are several posts

3

It is exactly the Yellow Flash of Death:

Here's the ref post I found:

Thanks for the Info.. yesterday I tried a search but it was way too late for my brain to function normally :smile:

4

Hi @frlobo,

I’ve seen that issue when the external flash on a core is damaged. Can you try writing something to that area of flash and reading it back to see if it works as expected?

dfu-util -d 1d50:607f -a 1 -s 0x00060000 -v -D core-firmware.bin
dfu-util -d 1d50:607f -a 1 -s 0x00060000:sizecount -v -U temp.bin

Thanks,
David

5

I will do this in a couple of hours when I get home. Thank you for your help! I was really lost!

1 Like
6

I was about to do the test. .But now my spark core only list with the internal small blue led and does nothing more!!! Not even the reset or power cycle, or long reset works!!

What to do now?

7

Ok.. I final managed to dfu mode my SparkCore.. Here's the result...

dfu-util -d 1d50:607f -a 1 -s 0x00060000 -v -D core-firmware.bin :

A bunch of :

Memory segment at 0x00000000 512 x 4096 = 2097152 (rew)
Downloading to address = 0x00060000, size = 78860
Poll timeout 50 ms

And dfu-util -d 1d50:607f -a 1 -s 0x00060000:sizecount -v -U temp.bin :

Device returned transfer size 1024
Error: Invalid dfuse modifier: sizecount

Thanks for your help. Let me know what to do...

8

Hi @frlobo,

Ahh, sorry, in this case sizecount was meant to be replaced with the size of the blob you read off the flash chip initially. So if you run ls -l, or dir depending on your system, and update that command to match that number of bytes:

dfu-util -d 1d50:607f -a 1 -s 0x00060000:78860 -v -U temp.bin

Then you’d want to compare those files with something like:

diff core-firmware.bin temp.bin

Thanks,
David

9

Oops.

@dave In that case.. The first command returned the same..

The second command returned:
bytes_per_hash=1024
Starting upload: [#############################################################################] finished!

And : temp.bin is 78860

And the diff command, returnes:
Binary files core-firmware.bin and temp.bin differ

10

Hi @frlobo,

Hmm, any chance you could open those files in a hex editor, or send them my way? I’m curious to see how badly they’re different.

This result would indicate that there is a problem with the external flash on that core. If you email us at hello@spark.io, and mention this thread, we can get you setup with a replacement core.

Thanks!
David

11

Il send the files tonight.

I do have a jtag shield and programmer should this be boot loader related??

12

Hi @frlobo,

I don’t think it’s bootloader related, but you can certainly always erase and re-load that if you want. :slight_smile: A feature we don’t have in the bootloader, but one that might be nice would be bad sector detection / workarounds for situations like this. So future bootloader improvements might be able to workaround failures like that, but that’s not the case yet.

Alternatively, if you wanted to just keep using that core, you could fish around in your flash chip and find a good sector, and bump up your OTA / backup firmware addresses to that sector instead, but that’s a bit fancy. :slight_smile:

Thanks,
David

13

Well… I would if I could… But I am not that good… :smile:

Thanks for your help…

Here’s the temp.bin file:

1 Like
15

Haven’t had any contact with regards replacing the device…

16

@dave Any news on the replacement core?

17

Hi @frlobo,

You sent us your shipping address and we confirmed on Thursday August 7th at 4pm, so we’re still working on getting you a replacement.

Thanks,
David