one chip mtu problem

RE: one chip mtu problem

Kenneth — Wed, 25 May 2022 14:25:07 GMT

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

RE: one chip mtu problem

ndc_bee — Wed, 25 May 2022 03:29:00 GMT

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.

RE: one chip mtu problem

ndc_bee — Wed, 25 May 2022 02:05:59 GMT

   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?

RE: one chip mtu problem

Kenneth — Tue, 24 May 2022 15:12:01 GMT

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

[quote user=""] 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.[/quote]

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