How does one determine the address space of Nios II program in MAX 10 UFM when using .pof file for internal configuration?

[gyuunyuu]

In the current system, the Nios II reset vector is set to On-Chip Flash. After power up the Nios II program is loaded into an external DDR2 RAM from the flash and executes from there. For Max 10 internal configuration, a POF is created where the SOF and Nios program Hex file is combined.

The Max 10 flash memory is also required to be used to store settings sent to the system through ethernet so that, those settings are used the next time the system boots. Therefore, the UFM stores the Nios program and also the program settings that can be changed at runtime.

At present the program stops execution after a while and it is suspected that the settings written into flash at run time are overwriting the Nios program although it is not clear how this can be confirmed.

So how can one determine the address span of the Nios II program in Flash memory and also, how to determine where to write our settings data into the UFM?​

[AnandRaj_S_Intel]

Hi Hassan,

Why can't we use information from .map file which is generated while generating pof file?

Which have address space details, for example:

Regards

Anand

[gyuunyuu]

​There are a few problems with that approach. Here is a screenshot of our .map file. Below it is the screenshot of the Qsys system's flash memory component settings.

The address space in the .map file seems to encompass the entire flash memory. The Nios .hex file is only 282kB. This is not so big that it should fill the entire flash memory.

Therefore, it is concluded that the .map file does not give the information we are looking for.

The address space information in the .map file includes the ICB which starts at 0x0. This is not even present in the Qsys settings where we can see that the UFM sector 1 starts at 0x0. It is not clear why such discrepancy exists.

It is not clear what part of UFM can be used by us in our C program to store settings for the program.

[AnandRaj_S_Intel]

Hi Hassan,

The .sopcinfo file and the system.h file generated for the Nios II toolchain includes address map information for each slave relative to each master that accesses the slave.

Check system.h file to access the on-chip flash using its base address.

Regards

Anand

[gyuunyuu]

I know the base address of the flash peripheral. My question is, once the POF file containing the Nios program is loaded into the Max 10 Flash (UFM region), how do I know what sectors are not occupied by the program and I can use them for other things? I don't want to overwrite the program code in the UFM.

The .map file does not answer this question apparently.

[AnandRaj_S_Intel]

Hi Hassan,

Okay,

The sectors occupied by .pof will be determined by Nios reset vector & on-chip flash.

Reset vector specifies memory space (offset & base) to the code memory, other memory sectors can be used for other things, Depending on on-chip flash sector access mode.

Example : if in design reset vetor is configured like

reset vector offset:0x000000

reset vector: 0x00080000

& On chip configuration same as image in previous post.

Code memory will be from 0x000000 to 0x0007ffff.

other sectors can be used for user appliction.

Let me know if this has helped resolve the issue you are facing or if you need any further assistance.

Regards

Anand.

[gyuunyuu]

It is not clear how you arrived at your conclusion. What assumption did you make for the program size to say that it will all fit into one sector?

Is there really no automatically generated file from the tool suite that can give this basic information about the program in UFM?

We want to know the precise address span of the program inside the UFM.

The Flash memory has much higher resolution than just sectors, it is further divided into blocks and pages. Therefore, it should be possible to specify a more precise address location for where the program ends in memory and we can use successive pages to store our own data.

[AnandRaj_S_Intel]

Hi Hassan,

Okay, Let me try to explain. nonvolatile

Then what for reset vector is used?? The reset vector is where our boot loader resides.

You can change the configuration scheme of on-chip flash and you can see the reset vector and sectors used for code memory in flash.

Noise code will be searched based on your nios reset vector.

We may not able to tell precise address locations for where the program ends in memory but we can tell code memory space by seeing the reset vector & it's offset.

Regards

Anand