Prevent Topology Failures When A System Has Multiple Salinity Sensors

[matt001k]

What changed?

Updates the LWIP task priority to 7 to allow LWIP to preempt low priority tasks and prevent blocking of receiving/transmitting data on the Bristlemouth network.

How does it make Bristlemouth better?

A bug was noticed on the Bristlemouth network that occurred when multiple salinity sensors were on a single network.
This bug did not allow the first topology request to succeed on a system.
The bug boiled down to the followingfor loop in aanderaa_conductivity.cpp:

  while ((pdTICKS_TO_MS(xTaskGetTickCount()) - start_time) < read_duration_ms) {
    if (PLUART::lineAvailable()) {
      read_len = PLUART::readLine(_payload_buffer, sizeof(_payload_buffer));
      if (read_len > 0) {
        debug_printf("%.*s\n", read_len, _payload_buffer);
        if (_sensorBmLogEnable) {
          spotter_log(0, AANDERAA_CONDUCTIVITY_RAW_LOG, USE_TIMESTAMP,
                      "tick: %" PRIu64 ", line: %.*s\n", uptimeGetMs(), read_len,
                      _payload_buffer);
        }
        clearPayloadBuffer();
      }
    }

This loop was preventing the lwip_thread from running.
The following is the state of the tasks before the for loop (rows from left to right represent task name, task state, task priority, task stack size, task number):

Task List:
USER           .X.2.3624.16
SerialTxTask   .R.2.318.4
IDLE           .R.0.100.2
tcpip_thread   .B.1.1924.11
Default        .B.2.310.1
Tmr Svc        .B.2.126.3
GPIO_ISR       .B.6.220.7
CLI            .B.1.2012.6
DFU Event      .B.11.964.12
sensorSample   .S.3.2012.15
BCMP           .B.5.846.13
Middleware Task.B.4.466.14
timer_cb_handle.B.5.986.9
L2             .B.7.1378.10
usb            .B.3.394.8
LPUartRx       .S.2.2000.17
ConsoleRX      .S.2.214.5

And here are the tasks after:

Task List after loop:
USER           .X.2.3624.16
SerialTxTask   .R.2.316.4
tcpip_thread   .R.1.1924.11
IDLE           .R.0.100.2
Default        .B.2.310.1
Tmr Svc        .B.2.126.3
CLI            .B.1.2012.6
DFU Event      .B.11.964.12
sensorSample   .S.3.2012.15
BCMP           .B.5.846.13
Middleware Task.B.4.466.14
LPUartRx       .S.2.2000.17
usb            .B.3.394.8
timer_cb_handle.B.5.986.9
L2             .B.7.1378.10
ConsoleRX      .S.2.214.5
GPIO_ISR       .B.6.220.7

The tcpip_thread with priority is in the run stateRafter the loop but cannot run until theUSER task (currently executing) is placed in a blocking (B`) state.

Upping the priority of the tcpip_thread immediately fixes this issue.

This might also help the throughput/robustness of the system.
With a low priority tcpip_thread ingested data packets might have gotten dropped if they could not have been handled in a timely matter!

Where should reviewers focus?

The description above.

Checklist

• Add or update unit tests for changed code
• Ensure all submodules up to date. If this PR relies on changes in submodules, merge those PRs first, then point this PR at/after the merge commit
• Ensure code is formatted correctly with clang-format. If there are large formatting changes, they should happen in a separate whitespace-only commit on this PR after all approvals.

[victorsowa12]

Awesome find! I think this change would be good to run through additional tests beyond HIL, maybe a couple long soaks with various configurations. I think that testing can happen after merging just to double check that this doesn't cause any unexpected behaviors.

[matt001k]

@victorsowa12 agreed! I will set up a system with a few nodes and have it soak overnight.