Flashing core from .NET (C#)

I am trying to flash a spark core from a C# application. I keep getting { error: Nothing to do? } response.

Below is my code

var url = string.Format("https://api.spark.io/v1/devices/{0}", sparkDeviceID);

using (var client = new HttpClient())
    client.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", accesstoken);
    using (var formData = new MultipartFormDataContent())
        HttpContent fileContent = new ByteArrayContent(Encoding.ASCII.GetBytes(rom));
        formData.Add(fileContent, "file", "file");
        var response = client.PutAsync(url, formData).Result;

        if (!response.IsSuccessStatusCode)
            throw new Exception("An error occurred during rom flash!");

        var responseStream = response.Content.ReadAsStreamAsync().Result;
        using (var reader = new StreamReader(responseStream, true))
            var result = reader.ReadToEnd();
    return true;

I believe the problem is the endpoint doesn’t see the file. Any idea on how to resolve this?

Also posted this on stackoverflow here -> SO Post

Hi @nodelink

In the curl command for flashing, it sets file_type=binary. How does your code do that?

If you run this command with curl -v for verbose mode, you might be able to see how the headers are setup better.

1 Like

I am actually passing a regular file to be compiled by Sparks servers.

I was playing with this interface just now and I noticed that it follows the general Spark convention that .cpp files do not have the preprocessor applied but .ino files do. In my case that meant that the file I saved off of the web IDE did not work as a .cpp file but did as a .ino file.

The return value is a JSON that tells you what went wrong, but like the web IDE, when things go wrong, the output is very long and the errors are at the bottom. Interestingly the first part of the response contains:

 "stdout": "Building core-common-lib\nmake[1]: Nothing to be done for `all'.\n\nBuil...

Which means that core-common-lib was up-to-date and did not need to be rebuilt in the compile farm. The actual error is way down.

Is this the kind of output you are seeing? Are you looking at the responseStream when you are debugging.

Here is the redacted curl -v output with it working so you can see the headers:

> PUT /v1/devices/<<coreid>>?access_token=<<access_token>> HTTP/1.1
> User-Agent: curl/7.37.1
> Host: api.spark.io
> Accept: */*
> Content-Length: 7317
> Expect: 100-continue
> Content-Type: multipart/form-data; boundary=------------------------ce2e79d30fa11944
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
* Server nginx/1.6.2 is not blacklisted
< Server: nginx/1.6.2
< Date: Wed, 29 Apr 2015 23:36:05 GMT
< Content-Type: application/json; charset=utf-8
< Content-Length: 71
< Connection: keep-alive
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
  "cmd": "Event",
  "name": "Update",
  "message": "Update started"
* Connection #0 to host api.spark.io left intact

My file is 7109 bytes so I am not sure what the 7317 content-length field has that is an extra 208 bytes. Might be the boundary, I don’t know.


@bko Thanks.

I took your advice and used Fiddler to monitor the actual request that was being generated when using curl to send a successful put request that actually flashed my device. I then compared it to the request my code was generated.

There was descrepencies that I resolved. It is all explained in this SO post.

1 Like