New Contributor
Occasional Contributor@jozephka99 Why is it ok to start programming the flash data from either address 0xAC00 or 0x2000, based on the addresses shown in the Flash IP configuration, while the addresses shown in the .map file are a bit higher? In the map it shows 0x8800 as start of CFM1, so 0x2200, and 2B800 as start of CFM0, so 0xAE00.
This is based on your lines 373 - 378 from the file manual_rsu.vhd. I'm guessing your code works, so it is correct to use the addresses of the Flash IP block and not to use the .map information.
ContributorIt is because the actual data -that differs from 1's- in that .rpd file begins from 0x8800 (0x2200) (CFM1) and 0x2B800 (0xAE00) (CFM0). Data before this addresses is full of "FF"s that is default value of OC RAM. (You can see that if you open the .rpd file with a HEX editor.) .map tells us that you don't have to change these addresses because you already erase the OC RAM before writing it and they are already in the default values. So you can either begin from addresses that shown in IP core like me, or you can use .map addressings. But I think .map addressings can change and it is not that easy to do it in dynamic way.
Occasional ContributorHmm, when I open the <project>_cfm1_auto.rpd, the first rule contains some data already, followed by some FF bytes, but not 0x200 worth.
I do see a lot of FF bytes starting a bit before halfway the file, so that's probably what you mean... Does this mean that I need to send the file back to front to the FPGA?
The file is attached as "proof", just inside a .zip because direct .rpd upload is not allowed here.
I'm generating the .rpd files through "convert programming file" and then ticking "create config data RPD".
Additional question: in "Options/Boot info..." I switch the "RPD File Endianness" to "Big endian" to save myself the bit-swap on the FPGA, right?
ContributorThe file that you send is just CFM1 file. It is cutted from <project>_auto.rpd file. If you look at that file you can see CFM1 section starts from 0x8800. The FF's from halfway is the empty spaces in the logic I think.
But here a new question appears. The CFMx_auto.rpd files cutted from 0x8800 and 0x2B800 but when write them to OC RAM, I write them from 0x8000 and 0x2B000. So in my understanding the exact addressing is not that important unless the .rpd's meaningful bits fits in OC RAM.
I swap the bits manually but it is more logical to do it from programming file converter of course.
Occasional ContributorI'm still having issues with programming the Flash...
As far as I understand https://www.intel.com/content/www/us/en/docs/programmable/683180/18-0/ufm-program-write-operation.html , I was able to convert this to a state machine in VHDL, programming_logic.vhd .
When I simulate this design with the correct platform (just dual boot IP and Flash IP), the simulation shows lot's of programming operations. So this lead me to believe this state machine is correct and I can indeed program a CFM sector of the Flash memory.
However, when I transfer my design to my MAX1000 FPGA (Intel MAX10M08), it goes to the Error state once the first byte has been programmed.
According to the guide, there are only 3 possible causes for this:
Any ideas to why the On-chip Flash IP core might indicate an error? Feel free to browse through the attached code.
(no idea to why this error can be caused is 'stupid'. FPGA and VHDL are not my strong suite, so feel free to spit out any cause for the error.)
