Thanks for the suggestions. Will try to make something workable from it. Obviously will require a lot more planning than my previous ad hoc methodology. I'll have to think long and hard about what the bounds are for data or state transitions being an error or not. Haven't thought about it that way. In my mind I was thinking states in a state machine, but now I have to bound the data values in each state, in order to test for out of bounds conditions.For T4.1-based controllers, since I can't use USB Serial while they are running, I log to RAM and read the data via hardware serial (UART). The main technique that I use for production systems is to log continuously to a ring buffer and then stop the udpates when a fault occurs. After the system enters a "shutdown" state, I can then read the data via UART and examine what was happening before and after the fault.
For data acquisition systems, where I want to log large amounts of data, I write to SD during operation, then transition to a "file transfer" state where I can retrieve the files via MTP (USB). The SD approach is the one that better fits the way you are trying to debug. SdFat has a built-in RingBuf template class that makes it easy to log at high frequency as long as the total data rate stays within bounds. I've done some bench-marking that shows it's possible to log to SD continuoulsy at 1 MB/sec using less than 1% of the CPU, with no disabling of interrupts and never blocking more than about 5 us. That's pretty good, and I've never had a data rate near 1 MB/s in a working system. It's always much less than that. The diagram below shows the basic idea of writing to the RingBuf from the ISR and then writing the data to SD in loop(). There are two rules you must follow to avoid blocking in the calls to SD's write() function. (1) ALWAYS write to SD in chunks of 512 bytes, and (2) ONLY write to SD when file.isBusy() returns false. RingBuf must be large enough to allow compliance with these two rules, and my rule of thumb is the buffer needs to be large enough for 50 ms of data. For 1 MB/s data rate, that means you need a 50KB buffer.
The easiest change for you to make would be to write to UART instead of USB Serial, but instead of writing on every interrupt, write only when you detect a problem.
May take me some time to plow through that, but I think it is worth it. My text mode logging was exceeding 1MB/sec and that was timestamp and state, and very little data, and that was not logging every interrupt, only the main loop. If I go to binary, I'll get at least 2:1 reduction, maybe a little more? That's still over FTDI rates. Hmm, may only be able to send out of bound data via FTDI, or log to SD card.