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.
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": https://github.com/BusPirate/Bus_Pirate/blob/cd9286dda95925b95f837a7a77e1baef2ba73006/Firmware/sump.c#L497-L505
https://github.com/BusPirate/Bus_Pirate/blob/cd9286dda95925b95f837a7a77e1baef2ba73006/Firmware/sump.c#L581-L592