Choosing non-standard SPI options freezes upon config recall

[MrAureliusR]

Hi there,

I'm currently trying to get a chip working that has idle high clock and trailing edge (so SPI options Polarity 2, Phase 2). Entering this mode after choosing these options works fine, but if you exit the mode and try to re-enter it, the Bus Pirate completely locks up here:

Mode > 6

Use previous settings?
 SPI speed: 1250 kHz
 Data bits: 8
 Clock polarity: 

The only solution is to delete the bpspi.bp file from within the Bus Pirate interface (removing it via the USB drive that appears doesn't seem to work, the file just re-appears after replugging -- possibly a separate bug?).

Steps to reproduce:
Open serial terminal
Hit m to choose mode, followed by 6 for SPI
Chose the options as follows: clock (doesn't matter), data bits (I've been choosing 8), Polarity 2, Phase 2, chip select 2 (active low)
Unplug the Bus Pirate OR use m to go to Hi-Z mode
Re-enter SPI mode and the entire board will lock up, not responding to any commands until after a power cycle.
I am using firmware built on commit 87b1d8c

[wyattearp]

@MrAureliusR -- Looking at the commits around yours, there were several bugs related to overflows, reentrancy, etc. fixed. I just tested with the current head and was unable to reproduce with a5d0e8a

Can you see if the behavior still exists on a current build for you?

[MrAureliusR]

Rebuilt with commit c667f1f and this solved this issue!
Awesome work everyone involved :)

[MrAureliusR]

Unfortunately, this has started happening again with my latest build (commit bbcff78). I can't remember what commit my previous build was, but it probably wasn't too old (less than a month?).
After I switch to SPI, it locks the BP up at the exact same spot as before, when trying to show the clock polarity. I have to delete the SPI config file to get it to work again.

EDIT: Just pulled the latest commit 1041c67 and same behaviour.

[wyattearp]

@MrAureliusR can you retry with 233c3b1? It looks like this might be a revert/merge issue from the PIO updates.

[MrAureliusR]

Sorry for the delay in response!
Just built with 5bbaed7 and still having the same issue. It locks up while trying to print out the clock polarity.

Do you want me to try the specific commit you mentioned? I could also try and do a git bisect to find where the bug was introduced?

[wyattearp]

If you've got the time to pull together a git bisect to narrow down the changes, I'm happy to help trying debug and find what the issue is. I recall hitting another menu option recently (but can't find it in my notes) that produce a similar issue. This makes me think it's a problem with persisting the data to the file system that's causing the problem.

[wyattearp]

Ok, I've done a little bit of digging, I think this might be an issue with the load / unload of the configuration. Looking through the git log, these stick out:

mode/hwspi.h

^c861a19 (DESKTOP-M9CCUTI\ian 2023-09-21 16:39:52 +0200 39) uint32_t dff;
6b15f34 (DESKTOP-M9CCUTI\ian 2024-04-02 14:59:27 +0200 40) bool read_with_write;
3059d74 (DESKTOP-M9CCUTI\ian 2024-07-25 16:07:07 +0200 41) bool binmode;
^c861a19 (DESKTOP-M9CCUTI\ian 2023-09-21 16:39:52 +0200 42) }_spi_mode_config;

In

BusPirate5-firmware/mode/hwspi.c

Line 59 in 5bbaed7

const mode_config_t config_t[]={

- there's no update to include the read_with_write or the binmode items. This by itself shouldn't cause the lock up, but it would likely cause those values to not be reloaded when it starts back up.

It does make me look at some of the storage handling here and wonder if there's a buffer issue that's causing it within these files.