Can't flash simple app from web ide & led says all ok

Troubleshooting
1

I’ve been unable to flash anything from the web IDE over the past day. I’m able to flash tinker from the app and control and read/write the IO pins, but I can’t even flash a simple LED flasher app, like in the tutorial. I get the flashing magenta on the sparkcore, followed by the breathing cyan, but no luck. I can still read/write the IO pins from Tinker, which indicates the flash failed.

Suggestions?

2

Would you please post your code so we can have a look? If you click Verify first before flashing are you getting the Code Verified. Great Work! message?

3

@ClintonKeith - Based on your comment, I assume that flash has been working for you in the days leading up to your current problem? In the IDE, are you saving your code before flashing it? How long does the flashing magenta last before it switches to breathing Cyan?

It could be that:

  1. Your code isn’t saved so it isn’t flashing correctly
  2. Your update is getting interrupted, so it’s reverting to the last good code on the Core (tinker)

Also, thanks @BDub for beating me to the punch.

4

@will No problem, I’m kind of sick right now and working on trying to solve issues is helping me learn things about the Core while keeping my mind off of how bad my throat & sinus feels :smile:

1 Like
5

Thanks gents. Like said, the tutorial examples aren’t working. Here is an example that doesn’t;

int LED = D3;

void setup() {
pinMode(LED, OUTPUT);
}

void loop() {
digitalWrite(LED, HIGH);
delay(250);
digitalWrite(LED, LOW);
delay(250);
}

Yes, I’m saving and compiling first. I’m doing everything that has worked over the past week+.

Question: if the “update is getting interrupted”, shouldn’t the IDE or the RGB LED indicate a failure in some way? Currently, for me, it’s not, and that lack of transparency greatly impedes development. I’d like to be able to make small changes to code many times during the day and not have to wonder if the update really happened or not.

Thanks again for any help or advice!

6

Right now, the RGB LED flashes magenta each time it gets a "chunk" of code in an update flashed to it. There is a known issue that the wireless flash can be relatively non-robust, and easily interrupted. If that happens, what you will see is the RGB go either solid magenta, or blank, depending on if it gets interrupted just before or just after it's received data.

We've been working for the last week or so on a significant improvement that should be pushed up shortly. In the meantime, if an update gets interrupted, resetting the Core and trying again is the best way forward. However, if it looks like it's successfully completing the update, there may be something else afoot.

Does it seem more like the process is getting interrupted, or that its finishing to completion, and simply isn't taking?

Thanks for your continued help resolving this one :smile:

7

I think the flash is getting disrupted, but it’s hard to tell (sometimes the RGB LED goes blank for a short period of time). The location I’m at has DSL rather than broadband, so there might be some more latency, etc in the connection with the flash chunks are coming in.

Good news that an update is OTW. I’ll hold off on trying to work this out until that happens. Is there a location where you announce these rollouts?

Cheers,
Clint

8

@ClintonKeith as I mentioned in our other thread (sorry for redundancy), the Spark blog is where we publish the actual results of our sprints.

9

FWIW: I have seen the solid magenta LED a few times after I flash the core. Every time I’ve seen this I just press the reset button, let it connect to the cloud again, and then try the flash again (which always has worked on the second try). I have a fast Comcast cable connection, so there should not be much latency… but latency can pop up from any link in the chain between my home network and the Spark Cloud server. If the OTA process is sensitive to latency, it will become an issue sooner or later. Sounds like you guys are working on a fix though.

Will this require new core OTA bootloader firmware, and will we be able to flash that OTA? I know how to do that the JTAG way already :wink: but I don’t think everyone will have those tools.

10

@BDub no–it won’t require a new OTA boot loader, it’s just going to help make the Core try harder to receive an update, even if a couple of packets get dropped. Basically, if a packet gets dropped, the Core will try multiple times to re-initiate the update, rather than just getting stuck if there’s consecutive packets dropped. We were playing in the office right before break with a robustness improvement that triumphed through an “update” that intentionally fumbled every 5th packet.

So, we’re hoping that, after we implement the improvement, we’ll see much closer to 100% successful OTA updates, even if there are dropped packets, etc. that disrupt the process.

Hope that helps to clarify.

1 Like
11

Any ETA on the robust flashing code?

12

Hi @ClintonKeith,

Yes! We implemented a fix to the firmware and cloud that recovers more gracefully from dropped chunks of firmware during over the air updates. When you flash from the build site now, this fix should be included, but it’s not yet in the “out of the box” update. I’m still seeing some over the air flashes fail occasionally, so any user experiences are helpful.

Thanks,
David

13

Thanks @Dave. I’ve been camping on the blog waiting for word on that fix, but it didn’t show up there. You mentioned that would be kept up-to-date on these fixes. I encourage you guys to do that.

14

Hi @ClintonKeith,

Happy New Year! We’re posting updates on our blog at the end of our sprints, which was posted on the last update, and another one will be at the end of the next sprint.

I posted about one of our over the air update fixes here: https://community.spark.io/t/solid-magenta-after-a-few-minutes-of-flashing-magenta/636/21 , and you can always follow the open source repos where these changes are happening, like here: https://github.com/spark/core-communication-lib/commit/c740d80b8001c4b733a280d255d8cbf194644423 .

You’ll notice that blog post went out on 12/21/2013 - http://blog.spark.io/2013/12/21/sprint-two/, and the over the air fix is mentioned: “We improved the stability of over-the-air firmware updates in the face of lossy networks.”

Thanks!
David

15

@Dave, the issue was discussed as a fix after 12/21, so I don't see how this particular problem resolution was part of the sprint before 12/21:

@will wrote on 12/26: "So, we're hoping that, after we implement the improvement, we'll see much closer to 100% successful OTA updates, even if there are dropped packets, etc. that disrupt the process."

12/26 is after 12/21, so I'm confused.

(by the way, I'm still having problems with the latest. I'll start another thread, because it might be a different cause).

16

Hey @ClintonKeith, sorry for the confusion. I’m on Spark’s sourcing and manufacturing team in the hardware division, rather than on the software team, so I knew a fix was in the works, but wasn’t aware it had been deployed. David, as one of our software engineers, will have much more insight into the current state of software bugs and improvements. Sorry for the misinformation.

1 Like
17

No worries @will. “They’re fixing things faster than I thought” is not a bad problem!