MAX10M08 Flash Accelerator

[Altera_Forum]

Hi, 

 I am working on a project using the MAX10M08 with Nios ii /f and Quartus Prime Lite 15.1.2.   Up to now i used the onchipmemory as instruction memory. But the goal is run from the onchipflash. The Guide “Nios II Flash Accelerator Using Max 10” describes the configuration of the Nios Flash Accelerator and the matching settings for the onchipflash IP.  The cachelinesize is set to 64bit according to the guide, because the Flash Wrapped Read Burstsize of the M08 is 2 (cachelinesize => 2*32bit). “Read burst mode“ of the onchipflash IP is set to Wrapping.    But there is a problem. With the settings mentioned above i can start a debuggingsession within eclipse, “nios2-download” verify of flash content is successful, but the debugger won’t jump to main() (harwarebreakpoints and databreakpoints are set to 4). If I click on “pause / halt processer” and again “run” the debuggingsession terminates.   Error: Processor failed to go into debug mode when requested.   So I used gdb with console, set a hardwarebreakpoint at the reset address. The processor jumps to the reset vector pointing to flash and stops. After a single step gdb hangs / the processor hangs.   I also tried setting the cachelinesize to 128bit and it works, but I don’t think that’s the correct setting for the flash accelerator with MAX10M08 and will cause problems / no increase in performance.   Is anyone successfully using the flash accelerator? I have attached my configurations and qsys design.   Thanks in advance!

[Altera_Forum]

How did you load the onchip-flash content? I don't think nios2-download can verify the flash content since you did not connect the Nios data master to the onchip-flash.data. 

 Can your application run correctly? Or is this just a debug session issue?

[Altera_Forum]

I programmed the flash using the "convert programming files" method, merging the sof and the flash.hex (make mem_init_generate) and programmed the pof with the quartus programmer. 

There is one thing to note: I don't have a licence for the /f core yet, so i can not merge the timelimited sof. Therefore i merge a non timelimited sof (empty project) with the hex and flash only the UFM and not the CFM. After that i configure the device with the timelimited sof. I hope this shouldn't be the problem?  Ok that is right the data slave must be connected to the data master of the nios. Strange that the verify was successful. So i tested this. I kept the data slave unconnected, built two different programs (program1 and program2) flashed the hex of program1 and verified against elf of program2. nios-download always says Verified OK.  With connected data slave, i get a Verify missmatch as expected.  Downloaded 20KB in 0.3s (66.6KB/s) Verifying 00020000 ( 0%) Verify failed between address 0x20000 and 0x24EF7 Leaving target processor paused   0x20000 is the reset address and baseaddress of the flash.  Verify against program1 elf succeeds as expected, so i think the flash content is correct.   For testing without debugger i added a PIO component to toggle a LED in a loop with alt_busy_sleep.   I used "nios-download --reset-target --go" to reset and start the processor without debugging.  

• The led does not blink with cachelinesize set to 64 bit. => core stuck? 
• Using cachelinesize set to 128 bit the LED starts blinking. 

  I don't think it is an debuging issue, probably the accelerator stalls the instruction bus?.

[Altera_Forum]

Do you see any timing failure reported in Quartus? 

 How did you manage on the bsp settings? Did you assign .text to the onchip flash in the linker tab? Did you disable alt_load? I assume XIP?  Did you try running "helloworld"?  Can you put up some signaltap at the Nios.flash instruction master/onchip-flash.data interface?  I did try simulation on 64 bit/2 lines and I can run hello world.  Have you tried 64bit/4 lines?

[Altera_Forum]

System looks ok. Connections/resets are proper. Simulation on the system is ok too. Side note is that onchip-memory is not aligned to byte or 32768. 

 Probably you should check with Altera AE for further debug.  For now, maybe you can try to workaround by using 128 bit line size.

[Altera_Forum]

Can you connect the instruction master to the onchip memory and retry?

[Altera_Forum]

Hasn't solved the problem either. 

 To keep you informed, I got in touch with an Altera AE and he told me that problem was found as bug in the RTL code of the Flashaccelerator Wait Request and the bug should be fixed in a future version of Quartus. Quartus 16.0.2 doesn't contain the bugfix yet.