MCUmgr Error: ATT request failed: input channel closed: io: read/write on closed pipe

[clockis]

Greetings!

We have been using an nRF52840 Development Kit for a while now and have been performing FW updates OTA (between the same 3 FW images, cycling and updating between them many times) by using the CLI commands of MCUMgr such as:

mcumgr --conntype ble --connstring ctlr_name=hci0,peer_name='Feel Gen 2 - 53615210' image list

These updates were performed smoothly with no issues and the nRF52840 was always responsive (always between the same three images).

This DK was stored away for two weeks and was revisited today to perform an update once again ( no one had access to it or changed its FW, I am the only person who worked on this and found it intact as expected )

Now after trying to perform the same MCUmgr commands(for the same three images) as I had been doing in previous weeks where they worked without issues, I am getting the following error message:

Error: ATT request failed: input channel closed: io: read/write on closed pipe

However, when performing the updates using the nRF Connect Android app they are performed correctly.

Nothing changed in the FW, DK or the PC being used to run the mcumgr commands. What could cause this behavior? 

Nothing changed in the procedure, it was for a demo I had prepared a few weeks prior and now that its time to perform the demo its not working. I have confirmed that everything is exactly the same as two weeks prior. The only thing that changed was that two weeks passed.

Thank you for your time and I look forward to hearing from you!

Best regards,

Stavros

[Vidar Berg]

Hi Stavros,

I don't recall seeing this error before, but I suspect it's coming from the Bluetooth stack. Are you running Linux? Could BlueZ have been updated in the meantime? Either way, if you have a BT HCI dongle available (remember to pass the new hci interface the mcumgr command), I suggest trying it to see if you get the same error. Other things you might try is to reboot the PC, run the command as root, or ensure there are no other active BT connections on your system when attempting DFU.

Best regards,

Vidar

[clockis]

After revisiting this process and running the mcumgr commands again on the Raspberry Pi (Debian Bookworm) I get the same error even when using (sudo with the mcumgr commands). Unfortunately I do not have a bluetooth dongle to test your suggestion, I have tried restarting the bluetooth module with all avaliable manners on Linux with no change. Do you have any other suggestions on how to resolve this or what could cause this?

[Vidar Berg]

I would suggest that you try scannig for LE devices using bluetoothctl to verify that you are able to interface with the built in BT HW on the pi.

[clockis]

I did connect sometimes (rarely) using bluetoothctl, but most of the time the connection fails. When scanning with bluetoothctl, the Nordic peripheral is always visible/discoverable without fail as are other bluetooth devices in the vicinity and the bluetooth scanning works as expected. Also, I can always connect reliably via the nRF Connect mobile app without any issues.

I also bought and tried with a USB BLE dongle (hci1 device). I am seeing the same behaviour, meaning the first few times I send the command:

sudo mcumgr --conntype ble --connstring ctlr_name=hci1,peer_name='custom_name' image list

The device responds as expected:

Images:
 image=0 slot=0
    version: 1.0.0
    bootable: true
    flags: active confirmed
    hash: 2041accf98a57e4f3d44cc74fa8b6b8d1e9a2867cac5ca0800274edfd258c0df
 image=0 slot=1
    version: 1.3.0
    bootable: true
    flags:
    hash: 095edffde2850443d4edfd18a270bf63caf5ed977e7097641001859d846110e7
Split status: N/A (0)

but all the other times after that, I get the same error:

Error: ATT request failed: input channel closed: io: read/write on closed pipe

(I do wait about 10 -20 seconds between attempts)

Sometimes when I send the command:

sudo hciconfig hci1 up

The following " sudo mcumgr --conntype ble --connstring ctlr_name=hci1,peer_name='custom_name' image list " command works once and outputs the same error if I try it again.

This behaviour happens regardless of whether I use the external dongle or the onboard RPi Bluetooth.

Most of the times It doesnt work, and I get the same error.

I have tried restarting Bluetooth (systemctl and hciconfig down/up), monitoring the Bluetooth logs with btmon, installing different versions of Linux (from Bullseye to Bookworm) and different versions of the BlueZ drivers. I get the same behaviour every time.

Any suggestions or tips you have would be very helpful! Thank you for the support!

[Vidar Berg]

It seems like the problem is not specific to mcumgr but rather a more general connectivity issue. Could it be something in your particular app configuration that is leading to interoperability issues with the BlueZ stack? Perhaps you could try programming one of the SDK samples, such as smp_srv to your board target to see if you experience the same issue when using different FW.