Unable to change maximum payload size for BLE communication on nrf5340 - function only changes maximum time - but not the length - without throwing an error

Question

Hi, 
 I am currently developing a custom BLE peripheral that can transmit data packets of 244 bytes via notification. Using e.g. LightBlue I can receive these notifications without a problem. In order to better be able to debug my peripheral I am trying to setup a simple zephyr BLE central using a nrf5340-DK. This central works fine, if I limit payload size to 20 bytes, but fails to receive notifications with larger payload sizes. 
 Looking at the throughput sample, I have tried to change the max tx length on my central like this: 
 err = bt_conn_get_info(default_conn, &info);
if (err) 
{
	printk("ERROR: Failed to get connection info %d
", err);
}
else
{
	if (info.role != BT_CONN_ROLE_CENTRAL)
	{
 printk("this is not configured as BLE central
");
	}
	else
	{
 printk("the current tx data length setting is %d
",info.le.data_len->tx_max_len);
 printk("the current tx time setting is %d
",info.le.data_len->tx_max_time);
	}
}

printk("=> switch to DLE mode, if possible...
");

data_length_req = true;

test_params.data_len->tx_max_len = 80;
test_params.data_len->tx_max_time = 2120;

printk("test_params.data_len->tx_max_len: %d
", test_params.data_len->tx_max_len);
printk("test_params.data_len->tx_max_time: %d
", test_params.data_len->tx_max_time);
err = bt_conn_le_data_len_update(default_conn, test_params.data_len);
if (err)
{
	printk("ERROR: LE data length update failed: %d", err);
}
else
{
	printk("LE Data length update pending...
");
	err = k_sem_take(&throughput_sem, THROUGHPUT_CONFIG_TIMEOUT);
	if (err)
	{
 printk("ERROR: LE Data Length update timeout");
	}
	else
	{
 printk("*** data length has been updated! ***
");

discover_params.uuid = (const struct bt_uuid *)&niederfrequent_serivce_uuid;
 discover_params.func = discover_func;
 discover_params.start_handle = BT_ATT_FIRST_ATTRIBUTE_HANDLE;
 discover_params.end_handle = BT_ATT_LAST_ATTRIBUTE_HANDLE;
 discover_params.type = BT_GATT_DISCOVER_PRIMARY;

err = bt_gatt_discover(default_conn, &discover_params);
 if (err)
 {
 printk("Discover failed(err %d)
", err);
 }
	}
}

err = bt_conn_get_info(default_conn, &info);
if (err) 
{
	printk("ERROR: Failed to get connection info after length update %d
", err);
}
else
{
 printk("the current tx data length setting after update is %d
",info.le.data_len->tx_max_len);
 printk("the current tx time setting is after update %d
",info.le.data_len->tx_max_time);
} 
 ... but surprisingly get the following output (first line is coming from the connected callback): 
 Connected: EB:50:34:EA:0C:80 (random)
the current tx data length setting is 27
the current tx time setting is 328
=> switch to DLE mode, if possible...
test_params.data_len->tx_max_len: 80
test_params.data_len->tx_max_time: 2120
LE Data length update pending...
LE data len updated: TX (len: 27 time: 2120) RX (len: 27 time: 2120)
*** data length has been updated! ***
the current tx data length setting after update is 27
the current tx time setting is after update 2120
[ATTRIBUTE] handle 16
ooo discover_func service discovered, start searching for characteristics
[ATTRIBUTE] handle 17
ooo discover_func characteristic discovered, start searching for CCC-services
[ATTRIBUTE] handle 19
ooo subscribe to notifications
[SUBSCRIBED] 
 It looks like I cannot change tx_max_len, but only the tx_max_time parameter by the call to bt_conn_le_data_len_update. Strangely the function call does not seem to deliver any error, even though it does not change the parameters in the desired fashion. 
 Since my code is very close to the throughput example, I do not really understand this behavior - the throughput example is running on the same board as expected. 
 Both, the throughput example as well as my central, however are producing the same warnings during build time, that some CONFIG parameters cannot be resolved. 
 warning: BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT (defined at
/Users/jens/MotionShapesMusic/Firmware/BMI270-spi/nrf/subsys/bluetooth/controller/Kconfig:107) was
assigned the value '4000000' but got the value ''. Check these unsatisfied dependencies:
BT_LL_SOFTDEVICE (=n), BT_CTLR (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT
and/or look up BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT in the menuconfig/guiconfig interface. The
Application Development Primer, Setting Configuration Values, and Kconfig - Tips and Best Practices
sections of the manual might be helpful too.

warning: BT_CTLR_DATA_LENGTH_MAX (defined at /Users/jens/MotionShapesMusic/Firmware/BMI270-spi/nrf/s
ubsys/bluetooth/services/fast_pair/Kconfig.fast_pair:93, subsys/bluetooth/controller/Kconfig:429)
was assigned the value '251' but got the value ''. Check these unsatisfied dependencies:
((BT_FAST_PAIR_GATT_SERVICE && BT_FAST_PAIR && BT) || (BT_CTLR_DATA_LENGTH && BT_CONN && BT_CTLR &&
BT_HCI && BT)) (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_CTLR_DATA_LENGTH_MAX and/or look up
BT_CTLR_DATA_LENGTH_MAX in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

warning: BT_CTLR_RX_BUFFERS (defined at subsys/bluetooth/controller/Kconfig:194) was assigned the
value '2' but got the value ''. Check these unsatisfied dependencies: BT_CTLR (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_CTLR_RX_BUFFERS and/or look up
BT_CTLR_RX_BUFFERS in the menuconfig/guiconfig interface. The Application Development Primer,
Setting Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be
helpful too.

warning: BT_CTLR_PHY_2M (defined at subsys/bluetooth/controller/Kconfig:513) was assigned the value
'y' but got the value 'n'. Check these unsatisfied dependencies: (BT_CTLR_PHY || BT_CTLR_ADV_EXT)
(=n), BT_CTLR_PHY_2M_SUPPORT (=n), BT_CTLR (=n). See
http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_BT_CTLR_PHY_2M and/or look up
BT_CTLR_PHY_2M in the menuconfig/guiconfig interface. The Application Development Primer, Setting
Configuration Values, and Kconfig - Tips and Best Practices sections of the manual might be helpful
too. 
 All bluetooth related CONFIG settings in prj.conf are identical to the throughput example. I am not sure, however, what else might be needed for initialization or configuration in order to work on the split core system of nrf5340 - do I miss something? There is a file called hci_rpmsg.conf that holds some parameters in the network part in the throughput sample, that I do not have in my program, because I do not understand what it does. Just copying the file did not do the job ;-). 
 I am working with VSCode and nrfConnect SDK 2.2.0 on a MacBook Pro. 
 I would really be happy for any advice on how to fix this strange behavior that I have spent quite a few hours already to figure out on my own. 
 Regards, 
 Jens