COMM_GET_VALUES_SELECTIVE returns something mysterious in3.56 fw that I am not asking for (which corrupts parsing code) about bldc HOT 3 CLOSED

By process of elimination, I discovered that this is the culprit:-

	if (mask && ((uint32_t)1 << 14)) {
		buffer_append_int32(send_buffer, mc_interface_get_tachometer_abs_value(false), &ind);
	}

Whether or not we set bit 14, we ALWAYS get this returned to us.

I don't know why - but it is a fact.

Here are 2 reply packets, as I got them over the wire (preceded with my binary bitmask for clarity):-

// 00000000 00000010 11100000 00000000 = 2 15 50 0 2 224 0 0 0 0 24 0 0 0 92 0 110 15 209 3
// 00000000 00000010 10100000 00000000 = 2 15 50 0 2 160 0 0 0 0 36 0 0 0 104 0 110 192 18 3

As you can see, the requests are different (bit 14 is NOT set in the second one), the reply mask is different (bit 14 NOT set), but the packets are both 15 bytes long (impossible, because I asked for 14 in one, but not in the second)...

The deeper and much more worrying problem here - this is not a code mistake, the code is perfect - it's some kind of compiler behaviour weirdness, or runtime corruption, or something... and if it's happening here, where else is it hiding?

from bldc.

&& operator is obviously typo - bitwise and & must be used

from bldc.

The && is the problem of course. This is fixed in FW3.57.

from bldc.