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.
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
Yes you could use a regular resistor. For this simple test any value would do, but 4k7 is never a bad choice
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
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.
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
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!
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?
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.
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
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 ;-))