Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12589 Discussions

Flashed NIOS II SOPC not working?

Altera_Forum
Honored Contributor II
1,196 Views

Hi, 

 

I have developed an NIOS II sopc with multiple custom components. System works absolutely fine whilst operating in NIOS SBT for Eclipse (Debug or Run mode). However when I flash both sof & elf to an EPCS 64 device, using Flash Programmer, I find that Nios runs OK (I can write data through an SOPC UART and NIOS acknowledges) but my custom components don't function! My SOPC custom components are memory mapped and controlled by Nios. I'm using Quartus 11.0 SP 1 and target device is Cyclone EP3C40F484C6. 

 

Has anyone any idea what's wrong? Any suggestions appreciated. 

 

Ken.
0 Kudos
7 Replies
Altera_Forum
Honored Contributor II
450 Views

 

--- Quote Start ---  

 

Any suggestions appreciated. 

 

--- Quote End ---  

Have you tested each of the SOPC components individually with the Avalon Verification IP suite? If you have not, how do you know they adhere to the Avalon specification? Perhaps you have read and write working, but only if those transactions are spaced far apart. 

 

If you have not used the Verification IP suite. Post the code for one of your components, and I'll put together an example testbench, and then you can take it from there. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
450 Views

What kind of function do your components implement? 

There's only a situation I can think of: 

Usually when the design works in Debug/Run mode but not with EPCS boot, you have a problem with memory initialization. Infact, the jtag debugger automatically takes care of loading all the required memory sections, but with standalone mode (epcs boot) this is demanded to the bootloader. I remember a similar case when I had to add ALT_LOAD_SECTION_BY_NAME(memory_name) macros in my application to force loading TC memory which otherwise would have not been initialized.
0 Kudos
Altera_Forum
Honored Contributor II
450 Views

Hi Dave, 

 

I haven't tested my SOPC components using the Avalon Verification IP Suite. I had assumed they were OK since the system worked 100% in Debug/Run mode but not with EPCS boot. Is this not the case? 

 

I just found the solution to my problem on the forum, see link below; 

http://www.alteraforum.com/forum/showthread.php?t=24156 

 

My problem related to the JTAG UART SOPC component used by the Debugger and as suggested by RichardA, setting Stdin, Stdout and Stderr all to 'none', in the BSP editor, allowed the processor to run at power up. I can only assume that the JTAG UART's IRQ (0) was hanging my code and preventing system operation.  

 

Thanks for your suggestion and offer, much appreciated. 

 

Ken.
0 Kudos
Altera_Forum
Honored Contributor II
450 Views

Hi Cris72, 

 

Thanks for your suggestion. I manage to get issue resolved OK, see post and link above. 

 

Cheers, 

 

Ken.
0 Kudos
Altera_Forum
Honored Contributor II
450 Views

Hi Ken, 

 

--- Quote Start ---  

 

I haven't tested my SOPC components using the Avalon Verification IP Suite. I had assumed they were OK since the system worked 100% in Debug/Run mode but not with EPCS boot. Is this not the case? 

 

--- Quote End ---  

By not testing the components, you can never know if your components work 100% of the time. 

 

Consider the case of a back-to-back read, or write, read followed by write, or write followed by read. These sequences are easier to generate with the verification IP suite than they are with a NIOS II processor, or DMA controller.  

 

Lets say your component does have a problem with a write followed by a read, and that transaction sequence gets generated rarely. How would you determine that the reason for your system lockup was that particular problem? 

 

I'd recommend simulating any Avalon components you create. 

 

 

--- Quote Start ---  

 

I just found the solution to my problem on the forum, see link below; 

http://www.alteraforum.com/forum/showthread.php?t=24156 

 

My problem related to the JTAG UART SOPC component used by the Debugger and as suggested by RichardA, setting Stdin, Stdout and Stderr all to 'none', in the BSP editor, allowed the processor to run at power up. I can only assume that the JTAG UART's IRQ (0) was hanging my code and preventing system operation.  

 

Thanks for your suggestion and offer, much appreciated. 

 

--- Quote End ---  

Glad to hear your current problem was resolved. Watch out for the next one though, it might be a little harder to fix :) 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
450 Views

Hi Dave, 

 

Thanks for the sound advice. I can readily appreciate the merits of using the IP verification suite to ensure Avalon interface compliance. I am quite sure there are many tricky problems attributable to issues in this area. 

 

Can't say the move to SOPC hasn't been painless. Thankfully the forum and the experiences of its members has been invaluable in getting me to near completion of my first SOPC design. 

 

Thanks, 

 

Ken.
0 Kudos
Altera_Forum
Honored Contributor II
450 Views

Hi Ken, 

 

--- Quote Start ---  

 

Can't say the move to SOPC hasn't been painless. 

--- Quote End ---  

 

I'm not totally happy with SOPC Builder or Qsys either. It does create the fabric very nicely, but it has lots of "issues". Luckily this forum has lots of members willing to share their experience. 

 

Cheers, 

Dave
0 Kudos
Reply