[SOLVED] Not able to put my core in stop mode (it just wakes up)

@netropo,

can you try this example:

void setup(){
    pinMode(D7,OUTPUT);
    
    digitalWrite(D7,HIGH);
    delay(1000);
    digitalWrite(D7,LOW);
    delay(1000);
    Spark.sleep(SLEEP_MODE_DEEP,60);
}

The behavior should be flashing green --> breathing cyan --> blue led on 1s --> blue led off --> sleep for 60s

Just want to confirm that your bootloader is fine :wink: If not, a simple patch will do the job :smiley:

3 Likes

Sorry for my ausence @kennethlimcp but yesterday a sort of community restriction was taking place against my user preventing me to post and even to send private messages!

I will reproduce here the conversation we had by private messages, just for the shake of documenting the problem.

The code above worked as expected, that is, my Core connected to wifi, led was on for 1 second, then off, then slept for 60 seconds, then wake up again.

By message you asked me to try this code as well

void setup(){
  pinMode(D7,OUTPUT);

  digitalWrite(D7,HIGH);
  delay(1000);
  digitalWrite(D7,LOW);
  delay(1000);
  Spark.sleep(D0,RISING);
}

With that code flashed my core goes to sleep but after few seconds wakes up again

Hello again :wink:
And we are back to the INPUT_PULLDOWN thing again - D0 is not allowed to float!!!

1 Like

Hi again @ScruffR!

You are absolutelly right. But even with the internal pull down resistor enabled the Core still wakes up. Could I use a regular resistor to ground to discard internal resistors missfunction? Any idea about the required value?

Thank you all for your patience and dedication to this weird problem by the way :smile:

Yes you could use a regular resistor. For this simple test any value would do, but 4k7 is never a bad choice :wink:

But I don’t think it will change anything anyhow (you tested several pins and I wouldn’t expect multiple pull-downs to be gone at once) - since the last code I posted works perfectly well on my Cores but doesn’t on yours, I’d expect you have some kind of hardware or Spark internal firmware issue.

Maybe you try some more factory resets and also a CC3000 deep_update (won’t have anything to do with this issue, but just to have it off the list).

I guess you haven’t got another Core to test it with :wink:

It somehow seems to me as if some other interrupt (~2sec) keeps waking the Core - but I have no idea which and how to nail it.

Browsing Github issues I’ve found this, which looks the same as my problem (comment #issuecomment-52681926)

Apparently it was solved in the bootloader patch but since I am having the same problem maybe it has returned altough the code does not seem to have been updated since 5 months ago.

Definetely that is the problem I am experimenting

And now… ITS WORKING! ^^

So, sumarizing:

In the begining I did not apply the bootloader patch even when I thought I did. What I did instead is flashing my Core with the master branch bin by error.

In my opinion, if bootloader patch is a production ready code should be merged into master branch and tagged.

However, if there is a reason for no doing so the documentation should be updated to point the need of switching to a branch before flashing since it not obvious if you follow README.md instructions

Anyways I am quite happy to see it solved since stop mode is a key feature in many projects I have in mind. Thank you all for your valuable time and dedication :smiley:

3 Likes

Would you mind explaining the exact steps you took to fix this problem? I’m not sure most of our users (myself included) would understand what you had to do to get this working. Thanks!

Sure!

Users who experiment the same problem just need to flash the core using the bootloader-patch-update branch of the firmware:

git clone git@github.com:spark/firmware
cd firmware
git checkout bootloader-patch-update
cd core-firmware/build

Then enter usb dfu/bootloader mode and flash their Core by executing

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

Is there a reason why that branch is not merged back into master? I think that it would help to avoid other users to get confused

Thanks for the steps. There’s an entire bootloader branch (https://github.com/spark/bootloader) but I’m not sure that’s related. Do you need to keep building with that special branch or is it a one time fix?

Seems to be a one time fix, since I’ve flashed a test project via web and behaviour remains as expected

That’s really strange. Did you have to unlock your bootloader first?

Nop, no aditional steps were needed

Awesome! That’s the step I was about to recommend if you are still facing the same issue.

You probably bought a core some time back and the bootloader is of an older version :wink:

Yes, but doesn’t he had to unlock the bootloader to upgrade it? Unless… the firmware he flashed does that automatically…

I think @satishgn made a special version of the core firmware that just patched the bootloader and that is what @netropo ran.

I thought that the “deep update” TI patcher also changed the bootloader, but I am not completely sure. It was discussed for sure but I am not sure what the decision was.

This only comes up for older cores since the newer production models have the newer bootloader.

Glad it is fixed.

1 Like

So for learning purposes, take a look here: https://github.com/spark/firmware/commit/30d618147fdf19ea0fd5bd8f7e96c5775e113b2a#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR1246

The entire bin data is in the user firmware itself and the firmware will unlock, erase and overwrite the existing bootloader region.

There’s some obvious risk here but i remembered timing the entire process but cannot locate the timings for this. It’s in the range where the patch get completed upon powering up and before the power can even be cut off :wink:

1 Like

Interesting.

I’ll check later myself but is that code snippet you linked me to run every time firmware is downloaded to the device (checking to see if the bootloader is patched)? Or is that just for that particular branch OP linked to?

I am not able to handle this "git clone git@github.com:spark/firmware" commands for download.
Isn't it possible to get a easy http:// download link for that stuff?

Ok, but now i got it. Was not the smart way but anyway. For luck i have install Ubuntu 14.04 some days ago, my first Ubuntu experience. You also have to install some stuff on Ubuntu and generate a ssh key and create a Github account but anyway it was much easier as on my win xp machine. After i downloaded the stuff via your commands above here, i put it in a zip file, drop it on my google drive account, extract it on my win xp, and use the described dfu-util command (for sure i have spark core on usb and in DFU Mode)

And now my Spark Core work also with the WAKEUP function.

Dear people from particle.io this was a big odyssey, not funny, i was annoyed more then one time.
I feel like, i bought a vodka and have to go by feet to Alaska to get ice for a cold drink.

First question - are you definetly working with a Spark Core and not with a Particle Photon?
I just wonder since you only joined up a few hours ago but the Cores were sold out quite a while back.

BTW: There is a nice and easy way to download a GitHub repo without git installed - and this will always be up to date (unlike any prefabricated zip files ;-))

Or just go to
https://github.com/spark/firmware/tree/bootloader-patch-update/build
and click on core-firmware.bin to download Raw

I think it’s not really Particles fault, since the what you asked for is there already.

1 Like