EclaireXL

On some cyclones the active serial pins can be directly used as IO. I tried that on here (cyclone v) but it didn't work, however it should be possible using the serial flash loader. This is what is internally used when programming via jic files. It has the option to expose the pins for use in the FPGA.

https://www.altera.com/en_US/pdfs/literature/an/an370.pdf

Think I have the hardware side connected, trying to talk to it now via firmware. Fingers crossed!

I found out I'd connected the hardware (in the vhdl) wrong, so no dice.

Reconnected what I thought was correctly, but no luck...
port map(
asmi_access_granted => '0', (never granted, always used by the fpga)
asmi_access_request => open, (request for use via jtag, ignore for now)
data_in(0) => spi_do, (send spi commands on data0)
data_oe(0) => '1', (output data 0)
data_oe(1) => '0', (input data 1)
data_out(1) => spi_flash_di, (input data on data1)
dclk_in => spi_clk, (clock - tried slow and fast)
ncso_in => spi_flash_select, (should be !sd selected)
noe_in => '0' (enable this thing)
);

I tried sending:
select flash
send 0xab
receive 3 dummy bytes (print in case)
receive device id
deselect flash

Just get fffffffffffffffffff...

Tried with 9f since I'm not sure ab is supported. Same result.

Got the scope on it and checked that the commands and chip select are correct. Look to be, but data out looks weird. Driven low, then gradually climbs like when there is a slow pull-up.

I thought about it and currently believe the problem is that cs_n is raised in between bytes (rather than at the end of a command sequence). I think I'm doing this without problem on the SD card, but for the flash it doesn't work.

foft wrote:

I thought about it and currently believe the problem is that cs_n is raised in between bytes (rather than at the end of a command sequence). I think I'm doing this without problem on the SD card, but for the flash it doesn't work.

So, a second more compatible Non Volative Ram chip is needed?

Yep, that was it. I can read and display the flash device id now.

The paves the way for saving settings, also it makes it fairly simple to load and flash a core from the SD card. That is for later...

sadosp wrote:

foft wrote:

I thought about it and currently believe the problem is that cs_n is raised in between bytes (rather than at the end of a command sequence). I think I'm doing this without problem on the SD card, but for the flash it doesn't work.

So, a second more compatible Non Volative Ram chip is needed?

Nah, just means I messed something up before which the SD card didn't care about (surprisingly).

Next step...
Add default settings to the jic. Then I can try reading/writing it. To write apparently I need to erase a page (to set to all 0xff), then write a page (to set some bits low). Reading looks trivial, though perhaps I have different addresses on different devices (v1 vs v2)

Step 1 done...

I add the settings to a jic file at a specified address.
Then I made the firmware load this if the 'settings' file is not found on the SD card.

Next step, saving!

Saving working too:)

foft wrote:

Saving working too:)

\o/

sadosp wrote:

foft wrote:

Saving working too:)

\o/

Wondering about whether to put a file system on the flash chip. Such as spiffs, which is aimed at flash chips and low memory.
https://github.com/pellepl/spiffs/
Probably overkill.

Tested as v1, working fine. Though I noticed that the i2c code hangs v1 (devices do not exist, I thought it'd be harmless...). Modified the platform register.