system runs whilst debugging but not on its own

[Altera_Forum]

Hi, 

 I have a custom board with an EP3C40F484C6, EPCS64, DDRII and an LCD touch panel. I am using quartusII 9.0 and NIOSII EDS 9.0. When I use the niosII ide to run my program within the hardware (Run -> Run As -> NiosII Hardware) everything works fine. When I program my epcs device using my created *.jic file from within quartusII my SPI core which talks to my touchscreen controller chip stops working. All other aspects of my system still work; LCD display, IO reads and writes, etc. but my SPI does not. I have an oscilloscope with SPI decoding function which I used to verify this problem. When debugging the SPI decoder shows data being sent from the cycIII but when it boots on its own with config from the epcs device no data can be seen by my SPI decoder.  Any help regarding this problem would be greatly appreciated!!  Thanks.

[Altera_Forum]

1 - Are you using a jtag uart and if so are you printing anything to standard out? If so, you may be overflowing the jtag uart's buffer at which point the system will hang indefinitely. 

2 - Is your processor configured to boot from the EPCS device? 3 - Is your processor configured to run out of onchip memory or some other memory? 4 - You should use the nios2-flash-programmer to program the EPCS device rather than the QuartusII programmer.  Jake

[Altera_Forum]

1 - Yes I am using a JTAG uart, although I did read about that issue already and have since removed all printf() statements. In any case my system does not hang, its only the SPI which does not run. 

2 - If you mean by MSEL bit settings then yes. My cycIII MSEL(3..0) bits are configured as 0010. This is the active serial (standard) configuration. I have also made sure that the epcs device pins are manually connected and assigned within the pin map in quartusII. Are there any other settings I may have neglected to set here?  I was a little confused on what setting to use in the niosII core for reset vector address. It is set to onchip_mem with 0x0 offset. My understanding is that a bootloader resides within the epcs core which runs code to transfer its contents to the FPGA. Then it gives control to the niosII which runs from the location specified within the above mentioned niosII setting. Does this sound correct to you or have I made an error here? 3 - Within the niosII ide I have slected the heap section to reside within my DDRII memory, this is used for LCD screen buffers. All other niosII memory sections reside within onchip memory. 4 - I have not tried using the nios2-flash-programmer yet, I will certainly read up on that and try it soon.  Thanks Jake! I'll let you know how it went.

[Altera_Forum]

All right, this is a little complicated. If you set the reset address of the processor to onchip memory, it will boot out of the onchip memory. If you set the reset address of the processor to the EPCS device, it will boot out of the EPCS device (which uses the boot loader you mentioned) but run out of whatever memory you've specificed in your system library project (sounds like onchip memory to me). If you are truly running in onchip memory, there is no need for you to boot from the EPCS flash because your processor code will actually be compiled into the FPGA image. 

 One thing I would double-check though is that you have enough onchip memory to support your software.  Anyway here is what you should be doing: 1 - Make sure the processor's reset address to onchip memory. Regenerate your SoPC system if necessary. 2 - Compile your software project. 3 - Compile your Quartus project. It is essential that this be done after you compile your software project or the software code will not be compiled into the fpga image. 4 - Program your EPCS flash with your firmware image (using either JIC method or nios2-flash-programmer).  Another thing you can try after the FPGA boots and the processor is running is to use the NIOS2 IDE to attach to the processor without re-downloading the code, then you can try and debug and see what is going on.  Jake

[Altera_Forum]

I used your method of debugging by attaching to the processor whilst it was running. From this I found that my spi core had its SSO bit in the control register asserted when loaded from the epcs device. When debugging this bit is randomly cleared at startup, which enables the spi to work. I changed my spi intialisation code to clear this bit at startup and everything works fine. Having this bit set somehow disables the spi from doing anything, which is not what it is supposed to do. The SSO bit is supposed to permanantly set the slave select bits that are selected in the slave select register. This doesn't make very much sense. However the problem has been removed but without satisfactory understanding. 

 If you can help with an explanation feel free. If you have better things to do (like me) don't worry about it.  Thanks for your help, much appreciated!!