App only works under debug

[Altera_Forum]

I've come across an interesting problem - I've generated a NIOS II/f core with some basic peripherals such as three PIOs for the toggle switches, red LEDs and 7-segment displays on the DE2-70 board. 

 Everything is wired up correctly in the Verilog modules which define the hardware and it also programs the board correctly. When I try and create a simple app which assigns the LEDs and 7-segment displays based on the toggle switches (like the tutorial on the DE2-70 board) - almost identical code apart from the fact I'm using the addresses generated in system.h by the SOPC builder, something bizarre happens...  Running under debug and stepping through the code the hardware works - changes the displays and LEDs as expected when individual lines of code are executed. When I try and either run continuously under debug or run without debug then nothing works.  To add more fun into the mix I'm using Windows 7 x64 as my main system and that took some time to get up and running I can tell you. Using v9.1 of Quartus and NIOS IDE.  Does anyone have any ideas why this might be the case? I'm running this over the standard USB blaster cable - which in the departmental labs (running Quartus 8.0 on XP) haven't had an issue but I'd like to use the OpenCores I2C controller which requires Quartus 9.1...  Many thanks Ed

[Altera_Forum]

I'd guess that your PIO writes are hitting the data cache

[Altera_Forum]

I understand what you mean (conceptually) but can you provide any pointers about how to rectify this issue?

[Altera_Forum]

Either get the compiler to generate 'ldio' or 'stio' instructions, or set the 2^31 bit on the addresses. 

Or disable the data cache! and (probably) put all your program data in tightly coupled memory.

[Altera_Forum]

I've actually sorted it thanks - used the proper I/O API to talk to the PIO controllers. It used to work using the volatile ints and so on in version 8.0 which is running on the lab PCs but they updated the NIOS core for 9.1 which means that stuff's now cached.

[Altera_Forum]

There is a gcc option to use 'ldio/stio' for volatiles. 

However that is quite rightly not the default (since volatile has slightly different semantics).

[Altera_Forum]

You know I spent about 2 or 3 hours trying to figure out why this wouldn't work for me until I realized the 'f' core has a data cache. The HAL Macros always worked fine but I was just doing an: 

  *pio_out_ptr = *pio_in_ptr;  There is also an instruction that will flush a cache line, however I'm not familiar enough with mixing ASM and C to tell you how to properly save any registers you would need to the stack. I'm sure a few minutes looking at the disassembly would solve that though.

[Altera_Forum]

I found the easiest way to solve this problem is to use the IORD_... and IOWR_... commands.

[Altera_Forum]

--- Quote Start ---  I found the easiest way to solve this problem is to use the IORD_... and IOWR_... commands.  --- Quote End ---    That's what I usually use, but I was trying for a "quick and dirty" solution, and was intrigued when it didn't work. I'd always worked with the slower cores and my pointer solution worked, so I had an "Ahha" moment when I figured out the problem (and the need for the IORD/IOWR functions).

[Altera_Forum]

In your case it may be easiest to arrange that the PIO addresses have the MSB set. ie are between 0x80000000 and 0x8fffffff. 

That will let you use normal C accesses instead if obfustacting the code with macros.

[Altera_Forum]

or use the alt_remap_uncached() function instead of setting the MSB, which will make the code a bit more portable if it is transferred on a Nios with MMU one day.