UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
3,120 Views
Registered: ‎05-23-2011

different memoryviews from different targets

Jump to solution

Hi


I worked some months on an project with an Zynq 7020 processor.

I implementet some new function in an Microblaze controller who is using 8 MB of the externel DDR (0x07000000-0x077FFFFF).

The Code for the Microblaze is copied by the A9 Core to the DDR and the Microblaze is sleeping like described in this article https://www.xilinx.com/support/answers/69133.html Downloading the project with the debugger works fine.

This week I startet to generat a self running project starting from the QSPI.

Now the trouble was beginning.

The Microblaze didn´t come to main(). In the first line there is an print instruction to an UART port, wich isn´t reached.

With the XSCT I can see that the programmcounter runs sometimes outside the memory are (0x06F......).

As I tried to understand why this happens I made some memory reads frome the code area at 0x07000000 and I saw that the memor is correct from the A9 core and from the MDM, but corrupted from the view of the Microblaze. Every second 32 bit instruction is doubled ((instruction on adress 0x07000000 can be read at adress 0x07000000 and 0x07000004 and so on).

It looks like some thing is going bad with the AXI Interface the DDR without debugger.

Some memory readouts can bee seen in the attached file.

Has anyone an idea wow can this appeare?


Kind regards

Thomas

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
5,587 Views
Registered: ‎02-01-2008

Re: different memoryviews from different targets

Jump to solution

Yes, what you describe makes sense.

 

When importing .hdf into sdk, a hardware project is created. Within this hardware project, ps7_init.c and ps7_init.tcl is extracted from the hdf.

 

When debugging in sdk, you have probably configured the debug configuration to initialize the PS using ps7_init. The debug configuration will use ps7_init.tcl.

 

The default SDK FSBL application project will contain a symbolic link to the above mentioned ps7_init.c. FSBL calls a few functions within ps7_init.c that will configure the HP ports to the configured widths, and will enable the level shifters between the PS and PL (the SDK debug configuration will also have a checkbox for enabling the level shifters).

 

So you may want to look at the differences between ps7_init.c for your non-microblaze and microblaze designs.

 

With respect to your last comment, I think you mean to change the interface width from the default of 64bits, to 32bits.

0 Kudos
5 Replies
Xilinx Employee
Xilinx Employee
3,100 Views
Registered: ‎02-01-2008

Re: different memoryviews from different targets

Jump to solution

Are you using the correct fsbl/ps7_init.c combination?

 

What you are describing sounds like a 32/64bit data width issue. When debugging via SDK, sdk will run ps7_init.tcl in order to configure the data width of the HP ports correctly.

 

When running from SD, FSBL will run ps7_init.c to configure the HP data width.

 

At first, I thought you were going to describe a cache issue but the doubling sounds like data width issue.

 

When you see the data doubling, try reading the control register, via the A9, to see what the HP datawidth is set to.

0 Kudos
Explorer
Explorer
3,074 Views
Registered: ‎05-23-2011

Re: different memoryviews from different targets

Jump to solution

Hi John

Thanks for your answer.

In my attached files there where only doubled values. I had also readouts with sometimes two correct values between the doubled ones.

The plattform I use is an self developed commercial product. To reproduce the boot-philosophy from the earlyer generation we had to write our own boot applikation. I think it is based on the fsbl project from Xilinx.

The boot applikation is loading the bitstream for the FPGA who is provided by the firmware project.

The firmware project has six build targets. Tree times a Debug and a Realise buildtarget for tree different hardware platforms (.hdf).

One HW-platform has no Microbaze. The two others have an Microblaze.
One of the two with the Microblaze works well, the other (new) one made the problem.
I take a look in these two projects. The older one use an 64 bit HP-Interface, but my new design only 32 bit.

The problem is that our booter project is based on the .hdf without any Microblaze (and without any HP-AXI in PL).
Perhaps in this situation is the problem.

Is this possible: our booterproject configure the platform without any HP-Interconnect.
The firmware project with the Microblaze configured with 64 Bit is working because 64 Bit is the default.
The firmware project with the Microblaze configured with 32 Bit is only working if it is downloaded with the debugger because the debugger configurs the AXI-Interface in the right width.
Booting this project in stand alone end up in the problems I had.

Could this be possible?

I would try to change the Interface with to 64 Bit next working day.


Kind regards

Thomas D.

 

 

 

 

 

 

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
5,588 Views
Registered: ‎02-01-2008

Re: different memoryviews from different targets

Jump to solution

Yes, what you describe makes sense.

 

When importing .hdf into sdk, a hardware project is created. Within this hardware project, ps7_init.c and ps7_init.tcl is extracted from the hdf.

 

When debugging in sdk, you have probably configured the debug configuration to initialize the PS using ps7_init. The debug configuration will use ps7_init.tcl.

 

The default SDK FSBL application project will contain a symbolic link to the above mentioned ps7_init.c. FSBL calls a few functions within ps7_init.c that will configure the HP ports to the configured widths, and will enable the level shifters between the PS and PL (the SDK debug configuration will also have a checkbox for enabling the level shifters).

 

So you may want to look at the differences between ps7_init.c for your non-microblaze and microblaze designs.

 

With respect to your last comment, I think you mean to change the interface width from the default of 64bits, to 32bits.

0 Kudos
Explorer
Explorer
2,947 Views
Registered: ‎05-23-2011

Re: different memoryviews from different targets

Jump to solution

Hi johnmcd

Yes, you are right. I mean "change the width to 64 bit".
With this change I can made a stand alone project running from the QSPI flash.

I checked the three.tcl files in the hardware projects and only found some changes in the way we generat a PL clock signal.
In one project we generat it from the IO PLL in the others from the DDR PLL, but it is allways the same frequency.
In the past we did some test to reduce the power consumption and one way was to reduce the numer of used PLLs.

Since I send the Microblaze into sleep after the reset I couldn´t download the microblaze.elf any more ("Cannot stop Microblaze. Microblaze is in sleep mode"). I had always had to make the stand alone project. This slows down my work.

Is there a more elegant way which allows it to use the debugger workflow and the stand alone?

Kind regards

Thomas

 

 

0 Kudos
Explorer
Explorer
2,902 Views
Registered: ‎05-23-2011

Re: different memoryviews from different targets

Jump to solution

Hi

After I changed the databus width for the AXI-HP interface, I changed back the .elf file for the Vivado project to my bootloop project which is polling a Bit in a register of an gpio instance.
This Bit is written by one cores of the Zynq after I copiede the Microblaze code into the DDR memory area.
This allows me to generat a stand alone firmware and also to debug with the same Vivado project.
Sending the Microbalze into sleep after reset will prevent the download of the .elf with the debugger.

This looks like it is the best solution for me.

Kind regards

Thomas

0 Kudos