SUMP mode does not handle long commands properly (garbage data in sigrok/pulseview)

[kwtaylor]

Trying out BPv3 and community firmware 7.1 from the forum with sigrok/pulseview, I noticed that logic analyzer results are just random junk.

The issue seems to be that SUMP mode is bailing back to binary mode before the acquisition is triggered. This happens after it receives a long command such as "c0 00 00 00 00" to set triggers.

After sniffing the serial connection data and then trying to re-produce the behavior manually, I determined that the long command logic sometimes only reads the 1st byte after "c0", then treats the rest of them as new commands -- and since "00" is the reset command, it heads back to binary mode.

I believe the root cause is that the command_buffer structure is a local non-static variable, so when the sump_handle_command_byte function returns, this state can get lost and reset to "0 bytes left":

Bus_Pirate/Firmware/sump.c

Lines 497 to 505 in cd9286d

	bool sump_handle_command_byte(unsigned char input_byte) {
	/*
	* The command storage buffer.
	*
	* No need to clear it first, as it will be properly initialized upon
	* receiving a long (5 bytes) command.
	*/
	sump_command_t command_buffer = {.bytes = {0}, .count = 0, .left = 0};

Bus_Pirate/Firmware/sump.c

Lines 581 to 592 in cd9286d

	case RX_COMMAND_PARAMETERS:
	/* Update command count. */
	command_buffer.count++;
	/* Fill buffer. */
	command_buffer.bytes[command_buffer.count] = input_byte;
	/* Check whether the buffer is full or not. */
	if (command_buffer.count < command_buffer.left) {
	break;
	}