Serial1.begin in class constructor hangs core

Same firmware wont flash - stucks in blue D7 LED and needs factory reset
I’m using Serial1, LiquidCrystal, OneWire, Wire and Dallas libraries.

Has anyone encountered any issues with these since today? I’m using all of them, so it is hard to locate which one is failing now.

My guess would be Serial1, because that was improved in the new release (now has a ring buffer so it reliably returns data). I don’t see any reason the others would have changed in this release, at least not off the top of my head.

I’ve commented out everything in main loop and setup and it still fails.
Serial1 micht be the issue, as it is initialized in Garan library class constructor.
This need fixing.

@zach @zachary Confirmed. Fired a bug https://github.com/spark/core-firmware/issues/134

Still can’t work with Serial1 properly :frowning:

Workaround: Move Serial1.begin() from constructor to void setup() {}

Zach, ryotsuke, there has always been problems doing hardware setup in class constructors since the core firmware main() overwrites any user inits. Perhaps this is the problem with Serial1.begin in this case. I would be nice to fix this issue.

The issues is most likely related to the ordering of statically declared object. There has always been an issue with the order things are constructed when declared static (at file scope)

http://www.parashift.com/c++-faq/static-init-order-on-first-use.html

in general since constructors can not return anything nothing that can fail should be done in them

@ryotsuke Best practices are to add an Initialize() method to your class. move the Seiral.Begin() to it Call it off setup()

Good point david_s5. For lots of folks porting arduino libraries, this has been standard practice. Perhaps it should be standard for all Spark libraries to avoid any future problems.

I would also jump in and say unless you’re flashing over DFU each time, this could be a side-effect of the somewhat semi-random “OTA flashing bug” – If this happens consistently after a few times of flashing the same firmware, then it’s probably not random, etc. :slight_smile:

All great points here… I wish these little gotchas were easier to convey and digest… I found this problem about a month ago :-/

Using DFU? It was working yesterday, broken after today’s updates (Serial1 issue) :smiley: