Is BLUENRG-2 working in DTM mode suppose to send some HCI Command Packets to controlling host MCU ?

[Wojciech]

Hi,

I'm using BLUENRG-2 chip with DTM (UART) FW as a BLE module for my STM32 processor. In general everything works - I'm able to set-up profiles, establish connection with central, send notification and receive data from characteristics.

To achieve that I'm using example code generated by BlueNRG GUI package - I'm sending commands to trigger notifications and advertising - I'm reacting to events generated by BlueNRG to receive data. So to summarize - i send HCI Commands and receive HCI Events.

However, from time to time, BlueNRG-2 sends me the HCI Command OPCODE=0xFD06 (which I identified as Aci_Gatt_Update_Char_Value) with handle of my profile - it seems handle of target char is not existing. It surprises me a lot because I thought that I'm the master here and I should expect only events... Moreover commands are just dropped by example code - only events are processed.

What could be the reason that BLUENRG generates such command ? is it safe to drop it as in example code ?

Best,

Wojciech

[Winfred LU]

Hi Wojciech,

This is strange. As far as i know, with DTM firmware BlueNRG-2 does not send HCI commands, it sends events only.

Not to mention an aci_gatt_update_char_value, it shall not send any command.

Is it possible to briefly describe the procedures you tested?

Let me try to replicate the issue with our EVBs with DTM FW, if it does exist.

Best Regards,

Winfred

[Wojciech]

Hi Winfred,

I made deep checking and I have detected one error - StreamBuffer which was receiving UART data was not read out fast enough and from time to time there was buffer overflow and few bytes of data stream from DTM were lost. This resulted in corrupted event messages (data from 2 packets merged together) and from time to time with false decoded commands.

Thank you very much for confirming that I should expect only events - this forced me to search for an error in other places.

Best,

Wojciech

[Wojciech]

Hi Winfred,

I made deep checking and I have detected one error - StreamBuffer which was receiving UART data was not read out fast enough and from time to time there was buffer overflow and few bytes of data stream from DTM were lost. This resulted in corrupted event messages (data from 2 packets merged together) and from time to time with false decoded commands.

Thank you very much for confirming that I should expect only events - this forced me to search for an error in other places.

Best,

Wojciech