Companion simulator crashes with External Module => Frsky Access R9m 2019

[Helipro]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Companion

Current Behavior

On 2.12.0-RC1 when External Frsky Access R9m 2019 is chosen simulator will not run. Simulator will run when another external protocol is selected.
External Frsky Access R9m 2019 works on 2.11.4 but not on 2.12.0-RC1
The Tx and Rx connect fine under Frsky Access R9m 2019. The problem is only with companion and not the tx.

Expected Behavior

Simulator to run without closing.

Steps To Reproduce

1. Open companion.
2. Make new model.
3. Set Aux1 to external module under hardware.
4. Select model specific external radio module protocol to frsky ACCESS R9M 2019
5. Simulate and companion closes

Version

2.12.0-RC

Transmitter

RadioMaster TX16S / TX16SMK2

Operating System (OS)

Windows

OS Version

Windows 11

Anything else?

No response

[pfeerick]

Not OS specific, reproducible on MacOS. Simulator is starting (i.e. with only Hardware => AUX1 => External Module and Model => External Module => Frsky Access R9M 2019 configured) and getting to the "failsafe not set" fullscreen alert, and promptly segfaults after clearing this screen (the simulator crash is why it takes Companion out).

(lldb) bt
* thread #30, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000000000000
    frame #1: 0x00000001282d9635 libedgetx-tx16s-simulator.dylib`pulsesSendNextFrame(unsigned char) + 277
    frame #2: 0x00000001281648a7 libedgetx-tx16s-simulator.dylib`mixerTask() + 231
    frame #3: 0x00000001282dbe16 libedgetx-tx16s-simulator.dylib`___lldb_unnamed_symbol24732 + 102
    frame #4: 0x00007ff80deeee4d libsystem_pthread.dylib`_pthread_start + 115
    frame #5: 0x00007ff80deea857 libsystem_pthread.dylib`thread_start + 15

[philmoz]

Crashes in this function because drv->txCompleted is null. Broken in PR #6634

bool modulePortSerialTxCompleted(void* ctx)
{
  auto st = (etx_module_state_t*)ctx;
  auto drv = modulePortGetSerialDrv(st->tx);
  auto drv_ctx = modulePortGetCtx(st->tx);
  return drv->txCompleted(drv_ctx);
}

[pfeerick]

#6909 May also be of some relevance here then also.

[philmoz]

#6909 May also be of some relevance here then also.

Not sure - different structures (etx_serial_driver_t vs etx_timer_driver_t).

[pfeerick]

Both issues stem from changes made by #6634, hence why it should be considered as part of #6909 review or an alternative fix (if something different is needed rather than in addition to).