You are not logged in.
Hi,
I'm trying to flash the SD card from the FPGA via the SD SPI module (I've added the pcore to the WARPLAB7.7.1 design and added the pin mapping in my .ucf file). I've also added the software support by adding the following init function into the wl_user.c code:
// These are implemented by sd_spi.c sd_fpga_ctrl_en(SSPI_ADDR); status = sd_rw_init(SSPI_ADDR); Everything builds fine but when I try to actually init from MATLAB sd_rw_init fails. Here is the code in question: int sd_rw_init(u32 ba) { int i, j; int init_tries; u8 sd_idle; u8 rx_byte; //SD cards I tested don't seem to require a slow clock for init //CLK_DIV param selects bit index in clk counter // Higher index -> faster SCLK // For 80MHz bus clock CLK_DIV=6 -> SCLK=20MHz simple_spi_set_clkDiv(ba, 6); //CMD0 sometimes fails on the first try - try it twice before punting for(j=0; j<2; j++) { //SD init requires >74 SCLK cycles with CS de-asserted and MOSI = 1 simple_spi_set_cs(ba, 0); for(i=0; i<20; i++) { simple_spi_write(ba, 0xFF); } //Wait for a while before sending IDLE command usleep(10000); //Assert CS and leave asserted simple_spi_set_cs(ba, 1); //Send GO_IDLE command // 0x95 is valid CRC for CMD0 msg // Later cmds don't need CRC (ignored in SPI mode) sd_send_cmd(ba, SD_CMD0, 0x0, 0x95); //Wait for command response // Response should be 0x01 = No errors, IDLE=1 for(i=0; i<32; i++) { rx_byte = simple_spi_read(ba); if(rx_byte == 0xFF) continue; else if(rx_byte == 0x01) break; } if(j==1 && i==32) { //Punt if both CMD0 attempts fail xil_printf("Error in CMD0 - no valid response\n"); return -1; } }
I get the ""Error in CMD0 - no valid response" in my debug serial console, so CMD0 isn't working for some reason. This worked on our WARPLAB7.3 design, has anything changed since then that might affect the sd_spi module?
Best,
Abeer
Offline
It's been a long time since I wrote that code and, to be honest, don't remember exactly how it works. A few things to check:
-Did you constrain all the necessary pins for the SD/SPI interface? Double check the <xps_proj>/implementation/system_map.mrp report. Search for "Number of LOCed IOBs" - that must be 100% (if not, at least 1 pin didn't have a LOC constraint in the UCF file).
-I think the SPI reconfiguration flow required a custom CPLD design; has your WARP v3 kit been updated with that?
-Verify that the w3_sd_spi_v1_00_a core was assigned a memory address accessible by the MicroBlaze CPU. One way to check would be to read one of the core's registers and verify you get the expected value (i.e. "Xil_In32(SSPI_ADDR + 0x0)" is the CONFIG register and should be non-zero after calling "simple_spi_set_clkDiv()").
Offline
The Number of LOCed IOBs is 100%
We have updated the CPLD with the appropriate design.
The problem may be in the memory address. Accessing parts of the memory space corresponding to the sd_spi core returns a constant value (of 10) and attempting to write to it via e.g. simple_spi_set_clkDiv does not affect the value.
My sd_spi instance is on the axi_interconnect_periph_80 bus. I assigned its address space to be below w3_iic_eeprom_FMC from 20B00000 - 20B00FFF.
Any reason any of that would be a problem?
Offline
Inability to read/write registers is definitely a problem. That interconnect and memory address should be fine. A few things to check:
-Is the sd_spi AXI_ACLK port connected to the 80MHz clock?
-Is the S_AXI_ARESETN connected to an active-low reset?
-Is the SDK software project using the updated hardware design?
Offline
- Yes: PORT S_AXI_ACLK = clk_80MHz
- Hm don't see port, is it part of the sd_spi core?
- Yes, I had to make edits in the WARPLAB7.7.1 EDK project and the SDK project is using the edited hardware design.
Offline
I forgot XPS connects the reset port via the AXI master-slave connection, so that's likely not the problem.
I'm not sure what else to suggest. If you cannot read/write registers in the sd_spi core, the core definitely won't work. One remaining possibility is the hardware in XPS and hardware project in the SDK are somehow out of sync. It's tedious, but it's worth cleaning hardware in XPS, re-building the design, then re-exporting to a fresh SDK workspace.
Offline