one chip mtu problem

[ndc_bee]

Hi nordic
   in our product nrf52832,guided by the tutorial developer.nordicsemi.com/.../README.html,we find something strange.
   as we have 3 nrf52832 chips in our product,two of them seem OK with the right aclmtu size.while the hci1 gets the default aclmtu.The three chips are in the same firmware,so we don't know why this will happen.
   pic1

   by the way,the hci1,the wrong mtu size one,receives strange bluetooth packets(the packets sent by our bluetooth products and usually the packet size is around 32 bytes) when we use btmon to monitor it and sometimes the kworker cpu usage is very high.
   pic2

   pic3

   here is the configuration of our zephyr project,we don't see anything strange for mtu configuration.
   pic4

[Kenneth]

Not sure if this is directly an nRF issue, but just to make sure I understand correctly:

   as we have 3 nrf52832 chips in our product,two of them seem OK with the right aclmtu size.while the hci1 gets the default aclmtu.The three chips are in the same firmware,so we don't know why this will happen.

Does the problem you experience always happen with the same nRF52832 chip, or does it simply depend on the order the chips are enumerated with the host (e.g. it's always the second one that is enumerated)? Does it also happen if only 1, 2, 3 or 4 are used? Have you found any kconfig option that cause all the chips to behave identically?

Kenneth

[ndc_bee]

   It's usually the second one that goes wrong.We have tested about 20+ our products,each product has 3 nrf52832 chips,only about 5 of the products are working fine with all the 3 chips.The rest gets a problem with the second one.It seems the second one not always goes wrong.
   We pick one for test,with only the second one for enumerating,but the result is just the same as the pic2.If we dont use the second one,i.e,we just use 1,3 for enumerating,they two just working fine.By the way,we also do a test and modify the CONFIG_BT_CTLR_DATA_LENGTH_MAX to 27,burn the firmware to the well working chip,the command hciconfig still shows the aclmtu 
   As mentioned before,the three chips are running the same firmware,we don't treat them differently.
   In this case,is there any good way to debug the chip?

[ndc_bee]

 Is aclmtu 27:7 the default option? Is there any way to change this default value? In this way,when the configuration failes,the default value will not be too small.

[Kenneth]

Everything is pointing to a problem with/on the host side here, that for unknown reason the host does not correctly enumerate one of the controllers, likely due to some race condition and/or host issue, reasoning for saying this is that the controller will just follow what the host configure it to. If you add a logic analyzer trace you can likely compare the UART communication between the chips to kind of prove this. As a side not, I can see that it says BR/EDR on your screenshot, while the controller only support BLE.

Kenneth