My core never gets to breathing cyan, it's only ever 'fast cyan'

Finally we meet. I thought I had escaped from it. Until last compile-server2 I never had it, interesting.

There is a difference between CFOD (slow) and CFOD (fast) right? I don’t get the typical slow CFOD… but I have seen the fast CFOD when I mess up things in my code, like allocate too much global memory.

1 Like

I think ‘Fast cyan’ is the core trying to complete the handshake with the server once the socket is open, and ‘slow cyan’ is the core trying to establish the socket in the first place.

1 Like

@Iv4n @BDub The biggest memory usage is definitely in the RSA handshake. Darn that big number math. The price we pay for security. :wink: I don't recall how much heap it claims max, but it's the bulk of the ~10K claimed by :spark:. Here are some pointers to relevant code for anyone who feels like digging into memory usage improvements.

The only call to allocate heap (malloc) in the entire firmware is in TropicSSL's mpi_grow:

This gets called in init_rsa_context_with_public_key when we send the initial message encrypted for the server:

It's also called (init_rsa_context_with_private_key) when the Core is processing the encrypted reply from the server in set_key, both in decipher_aes_credentials and verify_signature:

Our malloc/free implementation is extremely simplistic right now and does not handle fragmentation. See our stub for _sbrk:
https://github.com/spark/core-firmware/blob/master/src/newlib_stubs.cpp#L128

As I write this I'm noticing that the description for mallopt in the newlib docs says:

... releasing it back to the system in free (the space is released by calling _sbrk_r with a negative argument)

We have a stub for _sbrk but not one for _sbrk_r, though this might all be delegated under the hood. If you know otherwise, by all means submit a PR.

As always, pull requests welcome. @satishgn has been working lately on trying to statically allocate a buffer for the RSA math and free it up afterward. Not there yet, but we've got our eyes on the prize.

1 Like

oic. nevermind, wrong CFOD i guess. good luck solving whichever one it is!

Core id is 55ff6c064989495317402587. Always fast blinking cyan. I haven’t even had a chance to claim my id…

Hi @war1st ,

I haven’t seen your core try to connect to the server in the last week or so. It’s possible it has a bad copy of the server public key. Can you re-flash that key and see if that helps? Grab dfu-util binaries from here: http://dfu-util.gnumonks.org/ or with brew / macports if you’re on a mac, and then:

grab this file https://s3.amazonaws.com/spark-website/cloud_public.der
dfu-util -d 1d50:607f -a 1 -s 0x00001000 -v -D cloud_public.der

Make sure you’re using dfu-util version 0.7, and not the earlier ones.

Thanks!
David

@Dave
I reflashed my core with the new cloud_public.der successfully, but the problem stays.

Filter on vendor = 0x1d50 product = 0x607f Opening DFU capable USB device... ID 1d50:607f Run-time device DFU version 011a Found DFU: [1d50:607f] devnum=0, cfg=1, intf=0, alt=1, name="@SPI Flash : SST25x/0x00000000/512*04Kg" Claiming USB DFU Interface... Setting Alternate Setting #1 ... Determining device status: state = dfuERROR, status = 10 dfuERROR, clearing status Determining device status: state = dfuIDLE, status = 0 dfuIDLE, continuing DFU mode device DFU version 011a Device returned transfer size 1024 No valid DFU suffix signature Warning: File has no DFU suffix DfuSe interface name: "SPI Flash : SST25x" Memory segment at 0x00000000 512 x 4096 = 2097152 (rew) Downloading to address = 0x00001000, size = 294 Poll timeout 50 ms Download from image offset 00000000 to memory 00001000-00001125, size 294 Poll timeout 30 ms File downloaded successfully

@war1st So the :spark: core has never connected to the cloud i suppose?

Does it get detected by the Spark app you use to send the wifi credentials?

Sorry i’ll ask some questions but all to make it faster to resolve your issue.

  1. Router settings - Type? WPA/WEP? Channel Number?

  2. Try factory reset and resend your Wifi credentials are let us know the light status

@kennethlimcp Yep the core has never connected.

  1. Sometimes Spark app detects my core (the core connects to the router), sometimes not, anyway I use CoolTerm app.
  2. Router Air Port Time capsule II 2.4 GHZ, WPA, channel 6 (I’ve checked everything (or almost) that was in FAQ before posting here :smile: )
  3. I’ve tried it already.

So you basically entered the credentials using USB.

Can you try using the Spark/TI App and see if anything shows up after the Wifi Credentials are pushed to the core via Wifi?

I'm thinking that the Original firmware might be causing and issue for the lock-up at the last stage to get connected. Since your core never ever got connected. Really just a wild logical guess.

Try:

github.com/spark/core-firmware/blob/master/build/core-firmware.bin
dfu-util -d 1d50:607f -a 0 -s 0x08005000:leave -D core-firmware.bin

Or:

Testing connecting the core to another network

Another fix i thought of is the private key based on this post: (but highly impossible, right? @Dave)

Troubleshooting: My Core is flashing yellow/red lights after it connects to wifi - Troubleshooting - Particle

2 Likes

I think we haven’t seen @war1st’s core id pop up on the server side logs yet, so you’re right in that it seems unlikely that the private key is the problem. I’m guessing issues connecting to wifi at this point, or maybe that port is blocked on that network?

@kennethlimcp Ok,I upgraded firmware, now it really looks like core can’t connect to my router. It cycles fast cyan-fast green now. Basically my network consists of 2 routers - Apple Wi-Fi and Thomson TOW 770 (DOCSIS 3.0). The last one connects me to the Internet. @Dave Never thought about it,as I tried the Core with different networks and the result was always the same - fast blinking cyan. :frowning:

Okay, that’s good to know! If you haven’t yet, can we try running the patch programmer? This is just like flashing new firmware, just after you flash you hold the Mode button for 3+ seconds until it starts flashing magenta.

You can grab the binary here: https://github.com/spark/cc3000-patch-programmer/blob/master/build/cc3000-patch-programmer.bin?raw=true

And instructions are here; https://github.com/spark/cc3000-patch-programmer

Thanks!
David

@Dave Actually I left the Core for 20 minutes or so and… now its breathing cyan…wow…

@Dave @kennethlimcp but I’m skeptical about “self-repairable defects”…anyway do I need to run the programmer?

That’s great, it was just a matter of letting it sit? I wonder if it’s getting a really rough signal from the access point? Your core has an antenna, or does it have a u.fl jack?

edit: During manufacturing, we run the patch programmer on every core, but sometimes the factory mixed up cores, or rarely it seems like the patch didn’t always “take” properly. If things are working for you you probably don’t need to run it, but it doesn’t hurt anything to run it again.

@war1st Glad it’s connected! Just to make sure we have a solution for people in future,

  1. is your core a chip antenna or u.fl?

  2. after you flashed the firmware, you connected the core to Apple wifi or thomson?

Thank!

1 Like

@kennethlimcp @Dave first of all thank you guys! I’ll play around with my core and let you now if the connection is stable. The signal is good, nevertheless my core has a chip antenna. :frowning: But still sometimes (I say sometimes but actually it happened today early in the morning) I need to reboot my routers as the core blinks cyan-red again. But still I can not establish connection to the core using the Spark app. It allows me to connect my core to the same network, but soon after says “No cores found”. Are there any solution for that? By the way the second core I bought has the same problem. Core works with different network and has u.Fl jack, but from the same batch I suppose.

@war1st. Can you tell me what you did for
Yesterday?

Looking at what you mentioned,

  1. Do you have an Antenna connected to your u.fl core? If you don't, connection will be flaky.

  2. your core should be blinking blue waiting for wifi credentials. Using spark app and send, it should become solid blue, blinking cyan and eventually breathing cyan

  3. Was the core blinking blue when you sent credentials using Spark app?

  4. So the apple or thomson router gave a stable network?