Serial1 RX randomly dies on Boron 2.0.1/red SOS crash with second Serial1.begin

@toddparticle Thank you. A reasonable person could remain confused, after reading your update, as to whether this fix will fix the issue on Boron or solely on Argon where you reproduced it. Should there be an expectation that this issue will be fixed for Boron in the next LTS release? Thanks.

Thanks for the update, Todd.

When do you say next LTS, you are talking about 2.0.2? It would be great if this could be made available as a hotfix!

This change (for all Gen3 devices) is now available on the feature development line:

It will take some time to propagate to the Long Term Support (LTS) 2.x release line, and we have not announced a date for the next LTS release yet.


This seems like a serious enough bug that it should be implemented in the LTS line ASAP. Can you comment on what the timeline looks like for that fix to be in place?


Has anyone found a work-around for this? Thanks.

I have spent weeks finding out this is likely the problem we have, and unsuccessfully tried to find a work-around for it.

A bug is making products panic every few hours, and is not considered a severe bug for the LTS release line.

Lesson learned.

1 Like

Hi all here, can you please test on 2.1.0-rc.1, available now here? The relevant fix has been added via this PR and we are very interested in your feedback. + @thrmttnw

1 Like

I expect to test this after testing the i2c corruption fix in that same OS release.

Great this came to the LTS line so both Serial and i2c is working in the same OS version for B5, as downgrade options are very limited for these newer devices.

1 Like

Stuck with our show stoppers, it will be a while before I get back to this. The work-around for us has been to check for serial data less frequently. Loosing data, is less critical than the SOS crashes.

We had the same issue, we have been searching for months for the reason why our Borons have been rebooting every 1-40h with reset reason hard fault or sometimes assertion error.

We have a GPS module connected to Serial1, which sends data continuously. After discovering this thread some days ago, we could shorten the time to a system panic from about 1-40h in regular operation to a few seconds by sending synthetic GPS data as fast as possible.

2.1.0-rc.1 solved this issue for us.