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

[gitcnd]

I requested only 1 piece of data - the Vesc ID.
I get back this result (in base 10 bytes)

2 10 50 0 2 0 0 0 0 1 151 110 199 147 3

Those are:

2 = packet type
10 = number of bytes (correct)
50 = my request COMM_GET_VALUES_SELECTIVE (correct)
0 2 0 0 = the 32bit mask for what is being returned (just one single bit is set)
0 0 1 151 = spurious unknown data
110 = my vesc ID (correct)
199 147 = checksum
3 = terminator

The above breaks my CRC checking (because of the unexpected bytes).
If I ask for whatever that spurious thing is (set more bit masks), all is fine again, since it's getting and expecting that data.

My guess is that something in the compiler of the VESC firmware is choking on the bit-shifting of those masks inside commands.c

[gitcnd]

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?

[ledvinap]

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

[vedderb]

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