I've been tested for BT SIG however have met error which sent 0xc000 and got 0xc000. I expected to receive 0x8xxx. Command is LETestEnd. I tested with nRF51822 customer board.
I need your opinion for solving this error.
Thank you & Regards. Daniel
I've been tested for BT SIG however have met error which sent 0xc000 and got 0xc000. I expected to receive 0x8xxx. Command is LETestEnd. I tested with nRF51822 customer board.
I need your opinion for solving this error.
Thank you & Regards. Daniel
So you run BT SIG LE DTM according to Core specification v4.0/4.1? First step would probably be to verify that really these 16-bit words are visible physically on UART lines connecting your DUT with upper tester (e.g. by logical analyzer).
Btw. response 0xC000 is indeed valid LE_Test_Packet_Report_Event because only highest bit says it's report, all lower bits are representing packet counter in 0-32,767 range (0x0000-0x7FFF). So 0xC000 means 0x4000 aka 16,384 packets received during the test. I do agree it doesn't make sense if your test was with lower number of packets but you should definitely correct your DTM software if it doesn't just mask the 16-bit UART response with 0x8000 but assumes that the highest nibble must be 0x8 (it can be anything higher as well).
So you run BT SIG LE DTM according to Core specification v4.0/4.1? First step would probably be to verify that really these 16-bit words are visible physically on UART lines connecting your DUT with upper tester (e.g. by logical analyzer).
Btw. response 0xC000 is indeed valid LE_Test_Packet_Report_Event because only highest bit says it's report, all lower bits are representing packet counter in 0-32,767 range (0x0000-0x7FFF). So 0xC000 means 0x4000 aka 16,384 packets received during the test. I do agree it doesn't make sense if your test was with lower number of packets but you should definitely correct your DTM software if it doesn't just mask the 16-bit UART response with 0x8000 but assumes that the highest nibble must be 0x8 (it can be anything higher as well).