Jcole
Occasional ContributorJoined 3 years ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: Generic serial flash interface can't WR/RW past certain address limit
Found the issue, the state machine was passing the 22-bit RSU addressing to the erase command instead of the 32-bit byte address, so the address that was being used to erase was pointed to almost half of where we needed it to be.648Views0likes0CommentsGeneric serial flash interface can't WR/RW past certain address limit
I'm using a Cyclone 10LP and the flash is a Cypress S25FL256S. I've gotten familiar with reading and writing using the GSFI module but having a problem accessing the address past byte address 0x0001FFFF (Avalon memory address x07FFF). I'm using 4-byte addressing on all commands (Sector erase, write, and read) but when I try to read back the data written to 0x00020000 (Avalon memory 0x08000), I read back all 0's. Not sure if this is a limitation of the Cyclone 10LP or if I'm using the correct commands or not, both 3-byte and 4-byte commands result in the same behaviour. If I use address 0x0 to 0x0001FFFF the read and write operations work fine. Worst case this may be a damaged flash device.Solved817Views0likes3CommentsRe: Issue with Remote Update State Machine
I believe I was able to solve the problem, the addressing I was using for my Serial interface was incorrect and setting my pointer to a much lower location than intended. When the sector erase was executed I believe it was over writing a portion of the data that was used to hold the Factory image.715Views0likes0CommentsRe: Issue with Remote Update State Machine
To add new information gained during debugging, the issue of not returning to the factory image, seems to occur when my GSFI module is enabled in the FPGA code. If this module is not enabled, the system will return to the factory image. I do not have the GSFI state machine running when the RSU state machine is running (for obvious reason), but is there an underlying issue between the two modules? Does the flash used to house the image data need to be in a protected state for the RSU to work?884Views0likes0CommentsIssue with Remote Update State Machine
While looking for sample designs invoking the RSU via a state machine, I came across an older intel/altera design. The code is designed to repeatedly ping-pong between the factory image and the application image; however, I've gotten varied results. The FPGA will boot the factory image, then use the RSU to boot the application image successfully. When the application image tries return to the factory image, the FPGA does not successfully load and becomes completely unresponsive until reprogrammed. For my design we are using a S25FL256 to hold the SOF files. The Code for each state machine is below and attached to this post: Factory_image.v module c10rsu //factory image #( parameter APP_IMAGE_START = 32'h00800000, //copy this address directly from EPCQ datasheet parameter TIME_BETWEEN_STATES = 32'h01777777 ) // BLOCK START ADDRESS END ADDRESS // // Page_0 0x00000000 0x007FFFFF (0x006C16A3) Sector 0 to 127 // Page_1 0x00800000 0x0100FFFF (0x00EC16A3) Sector 128 to 255 ( input wire c10_clk50m, output [3:0] led ); // wire clk40; reg [31:0] data_in; reg [ 2:0] param; reg read_param; reg reconfig; reg reset = 1'b0; wire reset_timer = 1'b0; reg write_param = 1'b0; wire busy; wire [31:0] data_out; reg [31:0] count = 32'b0; reg [ 2:0] state = 3'b000; wire pof_error; //The count LED serves as a heartbeat, to see the design is functioning assign led[3] = (count[21] ); //LEDs to show the state assign led[2:0] = ~state[2:0]; //State Machine: //0: Reset the remote system update circuitry //1: Release the reset //2: Empty State //3: Set LEDs to indicate why we are in state //4: Set the address for the application image //5: Disable the watchdog timer //6: Boot the application image //7: Hold always @(posedge c10_clk50m) begin case (state) //Reset the remote system update circuitry 3'b000: begin count <= count + 1; reset <= 1'b1; param <= 3'b000; read_param <= 1'b0; data_in <= data_in; write_param <= 1'b0; reconfig <= 1'b0; if (count==TIME_BETWEEN_STATES) begin state <= 3'b001; count <= 32'b0; end end //Release the reset 3'b001: begin count <= count + 1; reset <= 1'b0; param <= 3'b000; read_param <= 1'b0; data_in <= data_in; write_param <= 1'b0; reconfig <= 1'b0; if (count==TIME_BETWEEN_STATES) begin state <= 3'b010; count <= 32'b0; end end //Empty state 3'b010: begin count <= count + 1; if (count==TIME_BETWEEN_STATES) begin state <= 3'b011; count <= 32'b0; end end //Set LEDs to indicate why we are in state and set AnF to 1 3'b011: begin count <= count + 1; reset <= 1'b0; param <= 3'b101; read_param <= 1'b0; reconfig <= 1'b0; data_in <= 32'h00000001; if (count[29]==1'b0) write_param <= 1'b1; else write_param <= 1'b0; if (count==TIME_BETWEEN_STATES) begin state <= 3'b100; count <= 32'b0; end end //Set the address for the application image 3'b100: begin count <= count + 1; reset <= 1'b0; param <= 3'b100; read_param <= 1'b0; reconfig <= 1'b0; data_in <= APP_IMAGE_START; if (count[29]==1'b0) write_param <= 1'b1; else write_param <= 1'b0; if (count==TIME_BETWEEN_STATES) begin state <= 3'b101; count <= 32'b0; end end //Disable the watchdog timer 3'b101: begin count <= count + 1; reset <= 1'b0; param <= 3'b011; read_param <= 1'b0; reconfig <= 1'b0; data_in <= 32'h00000000; if (count[29]==1'b0) write_param <= 1'b1; else write_param <= 1'b0; if (count==TIME_BETWEEN_STATES) begin state <= 3'b110; count <= 32'b0; end end //Boot the application image 3'b110: begin count <= count + 1; reset <= 1'b0; param <= param; //output read_param <= 1'b0; data_in <= data_in; write_param <= 1'b0; reconfig <= 1'b1; if (count==TIME_BETWEEN_STATES) begin state <= 3'b111; count <= 32'b0; end end 3'b111: begin //Still counting so it can be demonstrated that factory image is still working count <= count + 1; reset <= 1'b0; param <= param; read_param <= 1'b0; data_in <= data_in; write_param <= 1'b0; reconfig <= 1'b0; //No way out of this state without an external event, this is the error condition end default: begin count <= count + 1; reset <= 1'b0; param <= param; read_param <= 1'b0; data_in <= data_in; write_param <= 1'b0; reconfig <= 1'b0; if (count==TIME_BETWEEN_STATES) begin state <= 3'b000; count <= 32'b0; end end endcase end //Cyclone V remote update remote_update remote_update_inst ( .clock(c10_clk50m),//clk40), .data_in(data_in), .param(param), .read_param(read_param), .reconfig(reconfig), .reset(reset), .reset_timer(reset_timer), .write_param(write_param), .busy(busy) ); endmodule Application Image odule c10rsu //application_image #(parameter TIME_TO_FACTORY = 32'h08777777) ( input wire c10_clk50m, //input clk, output [2:0] led ); // wire clk40; reg reconfig = 1'b0; reg [31:0] count_to_factory = 32'b0; //The count LED serves as a heartbeat, to see the design is functioning assign led[2] = count_to_factory[21]; assign led[1] = count_to_factory[21]; assign led[0] = count_to_factory[21]; //counter for lights and back to factory. always @(posedge c10_clk50m) //clk40) begin count_to_factory <= count_to_factory + 1; if (count_to_factory == TIME_TO_FACTORY) reconfig <= 1'b1; end //Instantiate the remote update block remote_update remote_update_inst ( .clock(c10_clk50m), //clk40), .data_in(32'b0), .param(3'b0), .read_param(0), .reconfig(reconfig), .reset(1'b0), .reset_timer(1'b0), .write_param(1'b0), .busy(), .data_out() ); endmoduleSolved946Views0likes3CommentsIssue with RSU module or corrupted flash?
I have a RSU module in my boot-loader design running on the cyclone 10 LP eval board. I have a JIC file loaded with the boot-loader image at address 0x00, image 1 at address 0x400000, and image 2 at address 0x600000. Upon start up, the boot loader successfully loads and reconfigures the FPGA with image 1. Once Image 1 is loaded, its design is to run an exact copy of the the boot-loader statemachine, but this time pointed at address 0x00 (return to bootload). An issue arises when the reconfig signal is pulsed, the board goes into an unresponsive state and even remains in this state during power cycles. To fix the board, I must program the FPGA with a new image file (Sof or Jic). Any reason why the FPGA would become unresponsive?816Views0likes2CommentsSOF File written to flash by Quartus
I'm using a JTAG Indirect Configuration (JIC) file to load two SOF files in my flash using Quartus. When an SOF file is written to a flash location using Quartus, what is actually stored at those locations? Is the .SOF a wrapper for another file type that get written to the flash or is it the hex translation of the .SOF file that is written?758Views0likes2CommentsRe: Generic Serial Flash Interface addressing only generating 22 bit addressing for 24 bit flash
Your math is correct, but I'm slightly confused. If I'm not mistaken, the difference due to the word sizes of the GSFI being 32 bit as compared to the byte addressing of the flash.1.8KViews0likes0Comments