Skip to content

Implement S_CMD_S_PIN_STATE command - #4

Closed
dan-corneanu wants to merge 5 commits into
stacksmashing:mainfrom
dan-corneanu:implement_S_CMD_S_PIN_STATE_0x15
Closed

Implement S_CMD_S_PIN_STATE command#4
dan-corneanu wants to merge 5 commits into
stacksmashing:mainfrom
dan-corneanu:implement_S_CMD_S_PIN_STATE_0x15

Conversation

@dan-corneanu

Copy link
Copy Markdown

I have an FPGA dev board that has a flash SPI chip. Besides MISO, MOSI, SCK and CS pins it also has a CREST pin that needs to be driven low when you access the flash chip. Currently I have to manually ground CRESET every time I upload a new image to the flash chip.

I thought, I could take advantage of the S_CMD_S_PIN_STATE cmd and drive the CREST pin low on Output drivers enabled and high on Output drivers disabled.

I've implemented some code to handle the S_CMD_S_PIN_STATE cmd. However, the CREST pin (connected to GP5) does not toggle as expected. Could someone please have a look and tell me if I have missed something?

@dan-corneanu

Copy link
Copy Markdown
Author

@nezza @kazigk
Could one of you please have a look at this implementation of S_CMD_S_PIN_STATE and let me know what is wrong with it?

@kazigk

kazigk commented Apr 3, 2023

Copy link
Copy Markdown
Contributor

@dan-corneanu Sorry, just noticed your mention 😅

I just read through the serprog docs as well as the implementation in flashrom, and your code looks correct to me.
Try adding a little delay after you put that pin low (and before sending ACK), maybe it needs a few machine cycles to process 😉

@dan-corneanu

Copy link
Copy Markdown
Author

@kazigk why did you use a PIO implementation of SPI instead of using one of the hardware SPI peripherals?

@dan-corneanu

Copy link
Copy Markdown
Author

Coming back to this, after a long break, I am not able to reproduce the issue anymore. Most probably it was related to some electrical fault. I can confirm that CREST does work as expected and I am able to read and write the flash chip on my FPGA board.

I have done a bit of refactoring to move the output_drivers_disable/enable functionality to its own set of functions and to fully release all the pins on output_drivers_disable. This way someone else can control them after flashrom is done.

I am not sure if CREST makes any sense for your project, but if you find the rest of the refactoring useful I am happy to submit a clean PR excluding the CREST related code. Otherwise please feel free to close this one.

@anatol

anatol commented May 10, 2026

Copy link
Copy Markdown

I am looking for a SPI flash programmer that can enable/disable output and allow the device to boot. I believe rp2040+this patch does what I am looking for.

What is the plan for this PR. Does it look good to be merged?

@dan-corneanu

Copy link
Copy Markdown
Author

I am looking for a SPI flash programmer that can enable/disable output and allow the device to boot. I believe rp2040+this patch does what I am looking for.

What is the plan for this PR. Does it look good to be merged?

@anatol this PR is probably quite specific to my board that also has a reset pin that needs to be driven down during programming.
The other PR #12 , which I see you have already found, is the one you are probably interested into.

@dan-corneanu
dan-corneanu deleted the implement_S_CMD_S_PIN_STATE_0x15 branch May 10, 2026 22:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants