NIOS2 doesn't automatically run from external RAM, how to debug

[Oliver_I_Sedlacek]

I really need my NIOS2 to autostart and run from off chip RAM using the bootloader copy method. The trouble is that despite many readings of the handbook and multiple rebuilds of the design the code only runs if I start it from Eclipse. How do I debug what I've done wrong?

The hardware is the Trenz CYC1000 board which has an EP10CE25 fitted.

[JingyangTeh]

Hi

You could add the nios2 executable to the on chip ram in your design.

After you verify the behavior of your nios2 executable (.elf) using the debugger.

You could convert the elf into a hex file and place the hex file as an initialization file.

Using the command below to convert elf to hex

nios2-elf-objcopy -O ihex file.elf output_file.hex

Initialization of On chip ram

https://www.intel.com/content/dam/support/us/en/programmable/support-resources/fpga-wiki/asset03/hello-world-lcd-tutorial.pdf

Regards

Jingyang, Teh

Page 13

[Oliver_I_Sedlacek]

Please read my question very carefully.

My code is fully developed and works. It does not fit in on chip RAM, it's just too big. It is therefore placed in external RAM and if I download and run from Eclipse it all works.

I need the system to run independantly so I read the documentation on using the bootloader to copy code from configuration memory to external RAM and then run.

It doesn't work and I don't know how to debug the problem.

[JingyangTeh]

Hi Oliver

Could you share what issue that you are facing currently?

Have you managed to see the user guide on the boot copier?

https://www.intel.com/content/www/us/en/docs/programmable/683820/current/nios-ii-processor-boot-copier.html

I would check a few points.

1. The setting in the EMIF controller, whether it is according to the board RAM.
2. In the NiosII the vectors are selected to point to the EMIF.
3. In the BSP linker have you selected correctly.

Regards

Jingyang, Teh

[Oliver_I_Sedlacek]

Jingyang, yes I've used that guide for the boot copier.

1. The EMIF must be correct because the external RAM works fine. When the debugger runs the code everything works.

2. This is the most suspect area. I've read the documentation and my question is "how do I check that the vectors are correct?". What does 'correct' look like?

3. Same as point 2, what does 'correct' look like? I think the linker memory areas must be correct, see point 1.

Oliver

[Oliver_I_Sedlacek]

Keeping this alive, I really need a solution.

[Oliver_I_Sedlacek]

Any news. I know that if there's no activity then this will get closed even if I haven't got an answer.

Oliver

[JingyangTeh]

Hi Oliver

Sorry for the slow response.

With the elf file that you generated you are able to run from the external ram means the linker script settings is correct.

I believe in the BSP editor you have point the Linker Section to the external RAM.

When combining the bootloader are you using the command below:

alt-file-convert -I elf32-littlenios2 -O hex--input=<ELF filename>.elf --output=<HEX filename>.hex --base=<address of GSFI AVL MEM> --end=<address of GSFI AVL MEM> --reset=<reset vector> --out-data-width=8 --boot=<Quartus installation directory>/nios2eds/components/altera_nios2/boot_loader_cfi.srec

If yes could you try booting from the external flash and attaching the debugger and try looking at the memory region of the external ram and see whether the bootloader copied the code to the external RAM ?

Regards

Jingyang, Teh

[Oliver_I_Sedlacek]

Thanks for that. I'm unclear what you mean by 'booting from exteranl flash and attaching the debugger'. All I can seem to do is debug but then the external RAM contains what the debugger put there (screen shot attached). It's just a bunch of numbers to me so I don't know what that tells me anyway.

[JingyangTeh]

 

Hi Oliver

What i meant was, booting from the EP10CE25  flash.

After you boot from the EP10CE25 flash, try attaching the debugger only without flashing the image.

Unselecting the load image option in the screenshot below:

After only attaching the debugger try looking at the address 0x1 000 000.

See whether the values are the same when loading it using the debugger.

If it is not the same that means the flash could not be read by the bootloader.

In this case, you could try test reading or writing the flash separately if it is working properly.

Regards

Jingyang, Teh

Regards

Jingyang, Teh

[Oliver_I_Sedlacek]

Sounds daft but despite looking I haven't discovered how to just attach the debugger. What's the process?

I'm out of office for a week so please don't expect my next message before then, and please don't close the case.

[JingyangTeh]

Hi Oliver

I just notice that I did not attached the screenshot for the tab to just attached the debugger.

Please try taking a look at the previous comment on how to just attached the debugger.

Lets try attaching the debugger and see whether the bootloader is copying the code to the emif.

This will determine the next step to move.

Noted on this, we will keep this forum open till you get back.

Regards

Jingyang, Teh

[Oliver_I_Sedlacek]

I couldn't find a screen that looked like your screenshot but I found a way to 'connect only'. The external memory doesn't look the same as when I download from the debugger (also attached) so I think that is evidence that the code isn't being copied.

 

 

[JingyangTeh]

Hi

It seems like the bootloader is not copying the code over to the load address.

Could you double check the address that was used to create the hex fil is correct?

The Address of the base address and end address of the GSFI should be the value shown in the Address Map Tab in the Platform designer.

alt-file-convert -I elf32-littlenios2 -O hex--input=<ELF filename>.elf --output=<HEX filename>.hex --base=<address of GSFI AVL MEM> --end=<address of GSFI AVL MEM> --reset=<reset vector> --out-data-width=8 --boot=<Quartus installation directory>/nios2eds/components/altera_nios2/boot_loader_cfi.srec

After checking if that is correct we could try testing if the connection to the GSFI is working.

There is a simple project that you could create the test the connection. With that we could use system console to test the read/write to teh GSFI.

https://www.intel.com/content/www/us/en/docs/programmable/683419/24-1-20-2-5/flash-access-using-the.html

Regards

Jingyang, Teh

[Oliver_I_Sedlacek]

Crap crap crap crap, I'm now in a world of pain. I went through everything and reprogrammed the configuration and now I can't run the code at all.

This is a complete disaster as I really, really need to code to run so my project is now in serious trouble.

I'm reverting from revision control, and that's not looking good either.

[Oliver_I_Sedlacek]

It's been so long I've forgotten where the settings are. I'll look it up and get back to you.

[JingyangTeh]

Hi

Is the hello world program running from the debugger?

[Oliver_I_Sedlacek]

By taking the code image out of the FLASH so it just does the configuration I'm running again. I'm back to my original problem, with the additional handicap that I can't afford to break the system as the project is dependent on it.

[JingyangTeh]

Hi

Good news that you are able to get your code running back again.

You said that after you removed the code from the flash it is able to boot again.

Could it be that the code is overlapping with the FPGA configuration in the flash?

Have you tried the GSFI test to check if you could access the flash from jtag?

Regards

Jingyang, Teh

[Oliver_I_Sedlacek]

What is GSFI? Not this I guess http://bcpostfarmfoodsafety.com/haccp-certification/gsfi/

[JingyangTeh]

Hi Oliver

The GSFI is an IP by Intel.

In your case we could use that to test the read and write access to the Flash Storage to be working or not.

https://www.intel.com/content/www/us/en/docs/programmable/683419/24-1-20-2-5/flash-access-using-the.html

Regards

Jingyang, Teh