TE0722 DIPFORTy1 Memory write error - MMU section translation fault

[jon]

Dear Trenz Team,

I have a TE0722 DIPFORTy1 and I am having trouble with debugging it.

I am trying to run my code in debug on the ps7_ram_0 memory, and I then see that I only occupy 70.32% of it (of the 192kB that are available) (see 1st screenshot).
Then, when I try to program it, I get a "Memory write error at 0x15000. MMU Section Transaction Fault". This is weird, because if I go into debug mode with a smaller program, I can write and read from the memory locations  0x15000,  0x15001, and  0x15002 (which I tested with wrt and wrd commands from the XSCT Console, see 2nd screenshot).
This is really weird, as in the linker script the ps7_ram_0 starts at 0x00000, and has a size of 0x30000.

A not so nice workaround that worked was to modify the linker script and send some data to be written on the ps_ram_1 instead (see 3rd screenshot), and this works, but I don't like this solution, as I should be able to use all the 192kB of the first chunk of ps7_ram_0 memory.

How could I avoid the "Memory write error at 0x15000. MMU Section Transaction Fault" message and put it all into ps7_ram_0?

Thanks a lot!

[JH]

Hi,
TE0722 is without external RAM.

Can it be that you try to start application from QSPI, so you will do this: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842405/Zynq-7000+AP+SoC+-+AMP+Solution+without+External+Memory+Tech+Tip

PS: Your pictures has a poor resolution.

br
John

[jon]

Hi John,
A pleasure how fast you answer.

Please find attached the screenshots in better quality, sorry for that.
I don't understand why it fails, because it's within the memory address that's assigned in ps_ram_0.
I'm using the TE0790 to program it in debug mode.

Thanks,
Jon

[JH]

Hi,
TE0722 is without any RAM, see:
https://wiki.trenz-electronic.de/display/PD/TE0722+TRM#TE0722TRM-BlockDiagram
So you must do some special things there. From your screenshot (RAM01) you see that you try to use QSPI Flash as RAM. This is only possible under special conditions:
https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842405/Zynq-7000+AP+SoC+-+AMP+Solution+without+External+Memory+Tech+Tip
What you do is trying to programm qspi with downloadung application only, I think this is not possible in this way and system reboots with some older bootloader which is stored on the QSPI flash. And the message you see comes from the bootloader from the QSPI flash. --> Default Boot Mode is QSPI with JTAG enabled. On power up Xilinx bootrom (like bios on PC) try to find something bootable on QSPI flash. If it find something, it will start it otherwhise it will stop and you can programm it via JTAG(like you try at the moment)
See Xilinx link above which described how you can start application from flash without using ddr.
brJohn

[jon]

Dear John,

Thanks again for your answer. I understand that the TE0722 is a design without any DDR RAM.
I really want to do something simple with PWMs for a power electronics project. Hence, I just can't affort my system to "reset" with power.

The link https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842405/Zynq-7000+AP+SoC+-+AMP+Solution+without+External+Memory+Tech+Tip you sent me is complicated for my level of expertise.
I've seen, however, that in other posts (https://forum.trenz-electronic.de/index.php?topic=737.0) you recommend to write my code into the FSBL and just execute it from the FSBL.
I have managed to successfully do this, which is great, but my system still reboots every minute or so by itself, with the difference that before I got this "Secondary FPGA Image Loaded.." message, and now the program I wrote into the FSBL restarts (and again, I can't just lose my PWM for the power devices during the restart).

If you tell me that this is because the TE0722 is a design without DDR RAM, I really wouldn't understand why it's like this, as my code is successfully executing from the OCM.
And I don't know why the Zynq resets:

• I supply it with external 3.3V, and I have 3.3V on the board and even put a capacitor.
• I've tried putting a heatsink on the zynq and temperature reduces around 15degC, and stays stable
• I also monitor and trigger the POR_B signal to see if that causes the reset, but it's not the cause.

Any hint as to why the Zynq resets every so often (around every minute)?
The Processor System Reset block of the zynq is as in the example vivado files you provide.

I'd really appreciate some input

Thanks,
Jon

[JH]

Hi,
which power supply unit did you use? Laboratory power supply? Did you set some current limit?

Can you program QSPI flash with our reference design prebuilt Boot.bin?
Which assembly variant of TE0722 did you bough?
https://shop.trenz-electronic.de/en/Products/Trenz-Electronic/TE07XX-Zynq-SoC/TE0722-Zynq-SoC/

PS: We should maybe only usethis thread for the reboot problem, otherwise I've double works. ;-)
https://forum.trenz-electronic.de/index.php?topic=1520.0

br
John

[jon]

Good morning John,

Thanks for your reply.

I use a lab supply to power it (Siglent SPD3303X), it has steady 3.3V on the board, and a 10uF capacitor that I soldered between 3.3V and GND.
Current limit is set at 900mA, but the Zynq uses only 300mA, when flashing maybe goes up to just below 400mA.
I bought the TE0722-02 (https://shop.trenz-electronic.de/en/TE0722-02-DIPFORTy1-Soft-Propeller-with-Xilinx-Zynq-7010-and-16-MByte-Flash?c=348).
I have been able to program the QSPI flash from the reference built Boot.bin, yes (however, with flashing, I often need to reboot the Zynq with this https://wiki.trenz-electronic.de/display/PD/TE0722-Recovery, even if I try again flashing with the same program - this is weird).

This reset thing is really a problem... could it be that the FSBL has a watchdog timer or similar?
Is there any way of knowing what causes the reset?

Thanks,
Jon


 

[JH]

Hi,
TE0722 will be shipped with preprogrammed QSPI flash, which has a golden image(fallback fsbl on higher address). I think this golden image will be started. You can delete it when you erase the whole qspi, not only Boot.bin size(option in Vivado Flash programming GUI), siehe auch UG980.

the question is what caused the reboot...so when you use our default FSBL app (without changes), do you have the same effect?
br
John

[jon]

Hi John,

Thanks a lot for your tips.
Following your guidance, I erased all the Flash memory from the Vivado Hardware Manager. This worked fine - but it didn't fix the problem. --> Zynq still reboots.

I can also programed the flash with the default Trenz FSBL and prebuilt boot.bin file, and the Zynq also reboots by itself (but it happens much less often than with my design).

Differences between my design and the reference one is that I clock the FPGA at 100MHz, and I deleted the uartlite and the GPIO part of the design.
Could this reset issue have anything to do with this reset block in the attached image?

Thanks,
Jon

[JH]

Hi,
did you still see "Secondary FPGA Image Loaded.."?
Did you changed the address Range on the flash programming step in Vivado to the whole memory? -->UG908 page 66(on 20.2 version), it's chapter 6: Programming Memory device.


I still think you has some power problem. How did you connect you external power supply(which pins). What's the DIP settings of the TE0790 XMOD programmer?
br
John

[jon]

Hi John,

No, I don't see the "Secondary FPGA Image Loaded.." any more - which I guess is a good sign

Yes, when erasing the Flash memory I selected the Address Range to "Entire Configuration Memory Device".

It could very well be power issue, but I don't know why.
I checked the voltage on the board, and it's fine.

I'm attaching two photos of the hardware.

• First one is a photo from the top. I marked to which connections I have brought the 3.3V in. I also measured the voltage closer to the zynq with a multimeter, and increased the supply voltage just a bit to get it to 3.3V (it was 3.25V), but it didn't make any difference. You can also see where I have the electrolytic capacitor
• Second one is a photo of the TE0790 XMOD connected to it. The DIP settings are 1=ON, 2=3=4=OFF.

Note that I have soldered a (yellow) cable to a switch in the nRST pin such that I can reset manually the board without turning the supply off and on. I have a second TE0722-02 board without this switch soldered, but this is not the problem, as I can replicate the restart on the second board as well.

I also monitored the POR_B signal to see if that would fail, I set the trigger on it, but it doesn't go low when it resets.

This post here suggests a parasitic capacitance issue, that I don't think applies to me, because the reset switch that I soldered works as it should...https://forum.trenz-electronic.de/index.php?topic=737.0

Any ideas?

Thanks a lot,
Jon

[jon]

Dear John,

I just tried it with another voltage source (also 3.3V and current limit at 1A), and the Zynq still resets as before.

Thanks,
Jon

[JH]

Hi,

does your PC and you external power supply have the same gnd? GND is shorted via usb-cable maybe you has some potential difference.

Can you remove one time your power supply and check what's happens when you supply it via TE0790 (change DIPs to ON,OFF,ON,ON) and use our prebuilt fsbl app. Do you have the same affect there?


br
John

[jon]

Hi John,

So I made large progress I think. It seems to be none of all of the above.
Apparently it has to do with the watchdog of the FSBL.
This reset was occurring every 100 seconds, which coincides with this value in the main.c of the FSBL:

/************************** Constant Definitions *****************************/

#ifdef XPAR_XWDTPS_0_BASEADDR
#define WDT_DEVICE_ID      XPAR_XWDTPS_0_DEVICE_ID
#define WDT_EXPIRE_TIME      100
#define WDT_CRV_SHIFT      12
#endif

so what I did was comment the initialization of the Watchdog in the main.c of the FSBL:

//Status = InitWatchDog();

Now it resets like after 10 minutes... similar to what happens with the prebuilt FSBL and boot.bin image.

With this new progress... how would you recommend to totally disable the reset? how shall I proceed with the watchdog?

Thanks,
Jon

[JH]

Hi,
I'm not so sure, if this is the reason, but on TE0722 maybe.  FSBL is actually not designed by Xilinx to be the only app and there is a lot of generated code, without checking conditions because OCM is to small for complex code. I didn't run this fsbl app more than some minutes, but I also never heard from this kind of behaviour...

What you can try:
Open your Vivado Project and select Zynq IP configuration.
Disable WD and Timer on the IP (in this case, FSBL should not see it on BSP and it should be not enabled and this defines for wdt should be no set) and regenerate the design. Export XAS to Vitis (I would recommend to delete the old Vitis project). --> Use still our template repository with disabled DDR. and generate Boot.bin with this FSBL again.

br
John

[jon]

Dear John,

Thanks a lot for your reply. I've done as you suggested, disable the Watchdog and the Timers in the Zynq IP in Vivado, re-exported the .xsa file and then built a new Vitis project.
This also seems to work nicely as far as I've been able to diagnose (without commenting the Status = InitWatchDog(); line in main.c of the FSBL).

So please let me write down my workflow to flash the memory such that I can confirm it's correct:

Create the Boot Image: Here I have two files

• The FSBL that Vitis generates based on the .xsa file, where
  • I do this change: https://wiki.trenz-electronic.de/display/PD/DDR+less+ZYNQ+Design
  • I include my code that I want to be executed (in the same place where you include the TE code in the zynq_fsbl_app example
• The bitstream

Create the Boot Image:

• I include the boot.bin image I generated
• I use the fsbl_flash.elf file you provide in the prebuilt software of TE

Is this correct?

Thanks,
Jon

[JH]

Hi,
yes it looks ok on this way.
br
John