Closed kseverinkangas-zg closed 6 years ago
That was supposed to be a "never happens" condition so I wanted it noted - do you think it is actually working fine if the condition happens and we ignore it?
It isn't actually in interrupt context either, at least not in an RTOS build - that's "interrupt routine" is run from a high-priority thread, so it shouldn't be that problematic.
Probably the printing delayed the next interrupt handling (e.g. end of tx). Without the trace the system seems to work well.
@karsev what kind of tests were performed on the system to assess that this MR solves the issue?
On our side Tridonic we still see the issue, or at least some issue related to the radio, also with this fix. We are struggling to get a setup were we can get the issue to pop-up in a reproducible way, and thus are also unable to assess in a proper way whether it has been really solved.
Thank you a lot.
FYI: @MarceloSalazar @markus-becker-tridonic-com
Printing from the interrupt context caused serious problems in the 6lowpan devices. See -> https://github.com/ARMmbed/nanostack-border-router/issues/93