E-Series - ParticleSoftSerial causes device to crash

I am running Device OS 1.4.4 on E-Series LTE.

What I am tring to do
I am trying to utilize five different serial communication ports utilizing ParticleSoftSerial by @ScruffR for one of the serial ports and hardware serial for the other four.

Electrical Changes
Using just hardware serial, everything is working fine as I took the necessary approaches getting Serial2 to work. I moved the LED (blue, green) to pins C4 and C5 using timer 4 and removed the resisters to the proper locations.

Trying to get ParticleSoftSerial serial port working alongside the four hardware serials have been giving me some trouble. First I connected software serial to pins D2 and D3 which I found is using the same timer which may lead to why it doesn’t work properly. I then moved the pins to B3 and B2 which uses timer 3 expecting a different outcome, but I am getting the same problem.

When having the LED pin on (C4, C5) and using software serial on either (B3, B2) or (D2, D3), the led will blink red during each serial transmission and then after a random amount of time, between the first message to about 10 minutes (transmission occurs once a second), the software serial will stop working and the electron will crash and eventually restarts itself. If I move the LED pins back to its original location on Serial2, everything works fine.

I am at a lost on why this is happening?

Just for the record: Bricking commonly means to put the device into a state from where it cannot be revived.
Your description doesn’t seem to fit that bill tho’ - that’s more like locking up followed by crashing
(I changed the topic title accordingly)

ParticleSoftSerial does use SparkTimerInterval for the timing and due to interrupt latency the max baud rate is limited.

What version PSS are you using?
Does the library example work without issues?

Yes, bricking is not the correct wording for this, sorry about that!

I used both 0.0.7 and tried the new 0.0.11 which seem to both give the same result. I am only using a baud rate of 9600 which should be within the max baud rate limit.

Using the unmodified library example works perfectly fine as it doesn’t utilize the changed LED pins, but as soon as I change the pins for correct LED pins, it gives the same result. The line I added to the example is:

STARTUP(RGB.mirrorTo(54, C5, C4, true, true));

So the issue comes from the combination of PSS and RGB.mirror(), right?
Without mirroring your code using all serial ports still works, or not?

I’d have to check but that may be due to the way how the SparkIntervalTimer library auto-selects the HW timer for its purpose.
I haven’t thought of such a case and hence haven’t implemented a way to select the desired HW timer with my library.
I’ll have a look and will push an update as soon I find the time.

1 Like

Yes, it seems like the issue comes from the combination of PSS and RBG.mirror().

Without mirroring, Serial 1,4, and 5 work as expected and I am able to use software serial on pins D2 and D3. If I mirror the RGB pins to free Serial2 and use all four hardware serial ports with the extension of software serial, the device crashes after a random amount of time (< 10 minutes).

@Jeffrey, the SparkIntervalTimer allows you to specify a specific hardware timer in its begin() function with this form:

myTimer.begin(callback, 500, hmSec, TIMER7);

I suggest using TIMER7 since it is not used by DeviceOS whatsoever and will avoid the conflicts you may be seeing.

1 Like

I have investigated a bit more now and I found another possible reason for the crash but unfortunately Particle has still not provided a solution for this issue

While there was a workaround for the issue in the PietteTech_DHT library there isn’t for ParticleSoftSerial as there typically are not intermediate calls where the now disallowed detachInterrupt() can be placed.
So this part of the discusstion would be crucial to be followed-up upon but this issue seems to have become stale.

Maybe bumping that issue might help making it visible again.

However, I have added the ability to explicitly nominate two HW Timers for RX (defaults to TIMER7) and TX (defaults to AUTO) in the PSS constructor.
Could you test 0.0.12 please?

1 Like

Sorry for the delayed response.

The new version of ParticleSoftSerial works as expected and will help in our development. Thank you for getting this new push out. I also believe bumping that issue that you informed me about will be crucial to ensure intended behavior. I will be looking into this a lot more in the next couple days. Thanks for your help!

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.