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]

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]

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