Stacksmashing asked an interesting question on social media.
Is there an SPI programmer/reader that measures if another device is driving the lines while reading flash. This would be very useful when trying to dump flash while the chip is still on a board.
I suppose you could normally read flash several times and see if it gets the same value. But I wonder in a BP6 could do this.
Interesting question. I thought about it a bit and I’m undecided.
Could use the ADC to check voltages while reading/writing and report an error is contention is obvious (we see a 1.6v data or clock line on a 3.3volt bus).
What exactly is the use case? Dumping/flashing a chip in circuit while another device may have access at the same time? In what situations would one actually do that? This may be best solved upstream rather than trying to detect it. I’m interested though.
Stacksmasher is a professional reverse engineer. You may recall the Airtag hack. It’s something that would save him time. He’s used lots of different debuggers but knows of none that do this.
Sometimes when you power up a chip on a board, this also powers up the board and it will access the chip at the same time. It might access it for several seconds, then stop. An easy way to detect problems like this would be useful to him.
There are ways to work around this and he knows of all of them. But they take time. You might force the CPU into reset mode. And of course you could desolder the chip.
I’ve also wondered about getting the HOLD and WP pins.
When I flash a desoldered chip, I pull them up. But when on a board, they might be in the wrong state. But that’s another issue that’s easier to detect.
When I saw it on social media I thought maybe we could go bit by bit (bitbang) and constantly monitor the voltage on the pins to make sure they don’t deviate from a range during an operation. It would be slow, but maybe not as slow as desoldering a chip or messing with a PCB.
For WP and HOLD the pull-x system on the future board could probably do a good job probing that.
Brainstorming here. There could be an option where you do this for a short time to verify you are getting consistent values.
Perhaps re-read the same locations a few times?
This is one of the usecases that I had in mind when proposing the enhanced pullup and pulldown hardware for Rev 7.
So when you want to probe if there is some concurrent SPI access by another device, you set the high or low level of a signal not with the normal push/pull-driver, but instead use one of the low-ish pullups or -downs, for example 10k. Then use the ADC to verify that the voltage you are getting matches the logic level you set. If not, some other device interferes.
Why not use the push/pull-driver plus the ADC? Because the push/pull-driver, together with the ADC, is behind the io-port protection resistor (currently 330 Ohms). So when the interfering device is not behind a resistor, but directly connected and strong enough, the ADC of the Bus Pirate will see a voltage that looks ok.
When using pullups/downs instead, a conflict with another device will create a voltage divider and you will get a distinct ADC reading in the vast majority of cases.
What if, before trying to dump flash, the BP measured the I/O to the chip? If the I/O is toggling, then clearly dumping flash will have a problem. This is similar to the JTagulator I think.
I would think you’d want full coverage because the DUT could randomly interfere. That can definitely be an option though. As could when an error is detected pausing, and waiting for the bus to return to idle state, and then resume dump at last known valid address.
I believe the ADC sits directly on the IO pins so would detect the bus contention. I’m not in front of the schematic though.
Another thought - do spi as an open drain bus with pull ups. ADC max is 512k, at those speeds open drain should be fine. Then the contention won’t be dangerous and mismatch should be even more obvious.
Stacksmashing asked an interesting question on social media.
Do you happen to know what platform this was on? I can’t find it for some reason and I’d like to try to loop them in.
It was the dreaded platform that shall not be named.