19.1 Nios II firmware and hardware ported from 15.1 external sram self test fails

[kh99]

Cyclone V FPGA and Nios II firmware source originally developed and working on Quartus 15.1 has been ported to Quartus 19.1.

A firmware loader executing from parallel flash writes and reads patterns to verify 1MB of sram before moving the firmware application to sram and jumping to it.  This works in the 15.1 implementation.

This sram self test doesn't work in the 19.1 implementation (it appears the Nios II gets stuck) if testing the full 1MB of sram. The self test works if starting at an offset of approximately 10K bytes from the beginning of sram and going to the end of sram.

Has anyone else seen this issue and has information on what might be causing it?

[JingyangTeh_Altera]

Hi

Could you share more details on which part the NiosII is stuck?

If we skip the sram self test, is the NiosII able to run successfully?

Regards

Jingyang, Teh

[kh99]

Stuck might not be the best description of the Nios II behavior. The code snippet (executing in flash) where Nios II appears to not proceed normally is:

#define FOR_ADDRESS for( address.p8 = (uint8 *) BYPASS_DATA_CACHE( SRAM_BASE ); address.p8 < (uint8 *) BYPASS_DATA_CACHE( SRAM_BASE ) + SRAM_SPAN; address.p8++ )
#define DATA (address.byte[2] + address.byte[1] + address.byte[0])

static void fail( void );

///////////////////////////////////////////////////////////////////////////////

void self_test( void )
{
    u32_t address;

    FOR_ADDRESS
        *address.p8 = DATA;

    FOR_ADDRESS
        if( *address.p8 != (uint8) DATA )
            fail();

. . .

The first for loop completes. The Nios II Eclipse debugger "Resume", "Step Into", "Step Over", and "Step Return" buttons stop being selectable when I single step through the first iteration of the second for loop. The Nios II exhibits the same behavior when executing without the debugger.

I haven't skipped the selftest to see if the rest of the program executes successfully since the program after selftest is loaded to that portion of sram and jumped to. I'll try that.

Would installing the patch described in Article ID: 000080509, "FATAL: Cannot generate IP in a Windows environment!" (Bug ID: 14010725090) fix my issue?

[JingyangTeh_Altera]

Hi

The mentioned KDB should not be related to your issue

The error mentioned in the KDB is during the compilation of the project.

Could you share a screenshot of the Address Map of your project and the define of the SRAM_BASE and SRAM_SPAN of the code?

Regards

Jingyang, Teh

[kh99]

In system.h of bsp:

#define SRAM_BASE 0x4000000
#define SRAM_SPAN 1048576

[JingyangTeh_Altera]

Hey

Could you try adding a jtag bridge to the sdram controller.

Try the system console to access the first 10KB of the sdram if it is possible.

Regards

Jingyang, Teh

[kh99]

Hi,

We are not sure what to implement but here's our first stab:

1. add "JTAG to Avalon Master Bridge" - master_0 to the design

2. connect the SRAM reset to master_0.master_reset

3. connect the SRAM uas to master_0.master

Please let me know if this works.

Thanks.

[JingyangTeh_Altera]

Hi

Yes. That is correct.

Here are some docs on the tool that is useful.

https://www.macnica.com/content/dam/macnicagwi/apac/galaxy/public/en/downloads/technical-articles/ug-system-console.pdf

https://www.macnica.co.jp/en/business/semiconductor/articles/intel/134097/

Regards

Jingyang, Teh

[JingyangTeh_Altera]

HI

A suggestion could you try adding a delay in the c code? like a 5 second delay as a test before doing any sram test?

This is to ensure that the EMIF have completed the calibration before any read/write to the sram.

Regards

JIngyang, Teh

[kh99]

Hi Jingyang,

We added the "JTAG to Avalon Master Bridge" and used system console to verify that the first 0x3000 hex bytes of sram could be written, read, and verified.  Adding the 5 second delay didn't help.

I believe I've found what caused the issue, it's firmware related. Am testing now to verify this.

Thanks for your help.

[JingyangTeh_Altera]

Hi

Please do share which part of the firmware that you are referring to?

Regards

Jingyang, Teh

[kh99]

The linker information. It changed when the firmware was ported from 15.0 to 19.1 which caused the nios app executing sram selftest to be loaded in sram.

[JingyangTeh_Altera]

Hi

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, Please login to ‘https://supporttickets.intel.com/s/?language=en_US’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you on your follow-up questions.

Regards

Jingyang, Teh