Hard fault from nrf_log_frontend_dequeue()

Ah, but SDK 17.0.2 doesn't handle the reported issue well as it uses a blocking mechanism (CRITICAL_REGION_ENTER()) which stalls a fast interrupt when called from interrupt context in (say) SAADC or BLE; this is perhaps why using a short ADC sample time makes it worse.

It looks like the code you provided in the other question will not work in SDK 17.0.2, e.g. log_data_t no longer has the log_is_busy member.

Yes it does work in 17.0.2; you have to add the extra (new) field:

/**
 * brief An internal control block of the logger
 *
 * @note Circular buffer is using never cleared indexes and a mask. It means
 * that logger may break when indexes overflows. However, it is quite unlikely.
 * With rate of 1000 log entries with 2 parameters per second such situation
 * would happen after 12 days.
 */
typedef struct
{
    uint32_t                  wr_idx;          // Current write index (never reset)
    uint32_t                  rd_idx;          // Current read index  (never_reset)
    uint32_t                  mask;            // Size of buffer (must be power of 2) presented as mask
    uint32_t                  buffer[NRF_LOG_BUF_WORDS];
    nrf_log_timestamp_func_t  timestamp_func;  // A pointer to function that returns timestamp
    nrf_log_backend_t const * p_backend_head;
    nrf_atomic_flag_t         log_skipping;
    nrf_atomic_flag_t         log_skipped;
    nrf_atomic_flag_t         log_is_busy;     // This flag replaces the blocking use of critical region
    nrf_atomic_u32_t          log_dropped_cnt;
    bool                      autoflush;
} log_data_t;

Ah, sorry, I missed that the first time around. However, now I have added the workaround code in all three sections (log_data_t, top of nrf_log_init, top and bottom of nrf_log_frontend_dequeue), and am still getting an error upon BLE connection :/ Again, it only occurs for ADC acquisition time <10us and not for 10us and above.

New error, though: in nrf_ble_lesc_request_handler() at line 317: if (m_peer_keys[i].is_requested)

As an aside, are you handling unexpected interrupt errata 74:

3.15 [74] SAADC: Started events fires prematurely
This anomaly applies to IC Rev. Revision 3, build codes QFAA-Gx0, QFAB-Gx0, CIAA-Gx0.
It was inherited from the previous IC revision Revision 2.
Symptoms
False EVENTS_STARTED
Conditions
TACQ <= 5 μs
Consequences
The EVENTS_STARTED can come when not expected
Workaround
The module must be fully configured before it is enabled, and the TACQ configuration must be the last configuration set before ENABLE.