Memory write error while uploading project to Eclypse Z7

[gueste]

Hello everyone,

I have a problem uploading and debugging my baremetal code on the Eclypse Z7.

I'm using Vivado v2020.1 (64-bit), and Xilinx Vitis IDE v2020.1 (64-bit).

Usually it works fine but sometimes the following error message is thrown when clicking on the project -> Debug As -> Launch on Hardware: "ERROR    : Memory write error at 0x119000. Asynchronous Data Abort"

This is the Vitis Log output:

14:45:30 DEBUG    : Registering SDKStatusHandler to handle trace exceptions.
14:45:30 DEBUG    : Registered the core plugin as the backup plugin for storing repository paths.
14:45:30 INFO    : Launching XSCT server: xsct.bat -n  -interactive C:\ZZZ_Projekte_Xilinx_FPGA_LOKAL\DIRCM-H_V1_Vitis\Vitis\temp_xsdb_launch_script.tcl
14:45:30 INFO    : XSCT server has started successfully.
14:45:30 INFO    : Successfully done setting XSCT server connection channel  
14:45:30 INFO    : plnx-install-location is set to ''
14:45:30 INFO    : Successfully done setting workspace for the tool. 
14:45:30 INFO    : Platform repository initialization has completed.
14:45:31 INFO    : Successfully done query RDI_DATADIR 
14:45:31 INFO    : Registering command handlers for Vitis TCF services
14:48:02 INFO    : Connected to target on host '127.0.0.1' and port '3121'.
14:48:02 INFO    : Jtag cable 'Digilent Eclypse Z7 210393AD74DAA' is selected.
14:48:02 INFO    : 'jtag frequency' command is executed.
14:48:03 INFO    : Context for 'APU' is selected.
14:48:03 INFO    : System reset is completed.
14:48:06 INFO    : 'after 3000' command is executed.
14:48:06 INFO    : 'targets -set -filter {jtag_cable_name =~ "Digilent Eclypse Z7 210393AD74DAA" && level==0 && jtag_device_ctx=="jsn-Eclypse Z7-210393AD74DAA-23727093-0"}' command is executed.
14:48:08 INFO    : FPGA configured successfully with bitstream "C:/ZZZ_Projekte_Xilinx_FPGA_LOKAL/DIRCM-H_V1_Vitis/Vitis/DIRCM-H_V1/_ide/bitstream/design_1_wrapper.bit"
14:48:08 INFO    : Context for 'APU' is selected.
14:48:08 INFO    : Hardware design and registers information is loaded from 'C:/ZZZ_Projekte_Xilinx_FPGA_LOKAL/DIRCM-H_V1_Vitis/Vitis/design_1_wrapper/export/design_1_wrapper/hw/design_1_wrapper.xsa'.
14:48:08 INFO    : 'configparams force-mem-access 1' command is executed.
14:48:08 INFO    : Context for 'APU' is selected.
14:48:08 INFO    : Sourcing of 'C:/ZZZ_Projekte_Xilinx_FPGA_LOKAL/DIRCM-H_V1_Vitis/Vitis/DIRCM-H_V1/_ide/psinit/ps7_init.tcl' is done.
14:48:09 INFO    : 'ps7_init' command is executed.
14:48:09 INFO    : 'ps7_post_config' command is executed.
14:48:09 INFO    : Context for processor 'ps7_cortexa9_0' is selected.
14:48:09 ERROR    : Memory write error at 0x119000. Asynchronous Data Abort

--> The execution stops here.

 

Usually the error is removed by restarting the Vitis IDE, Vivado and the FPGA board but this time even restarting the computer multiple times doesn't help.

I'm glad for any advice.

Thanks.

[elodg]

Test other applications like hello_world, and the Zynq DRAM Test example. There could be an issue with your hardware platform, specifically with the PS configuration. Use our board files with the Zynq Preset for the hardware platform.

 

[gueste]

I'm currently using your board files and the Zynq preset for the hardware platform. The attached image shows my current Vivado project configuration.

I just figured out that the problem seems to be connected to the "xgpiops.h" library.
Including the library is not a problem but using the functions included.
 

XGpioPs_Config *gpio_cfg_ptr;
XGpioPs GPIOs;
gpio_cfg_ptr = XGpioPs_LookupConfig(GPIO_DEVICE_ID);
Status = XGpioPs_CfgInitialize(&GPIOs, gpio_cfg_ptr, gpio_cfg_ptr->BaseAddr);

Everything works well until adding the function "XGpioPs_CfgInitialize()".
This seems to screw up the program.
Though it is still possible to build and load it onto the Zynq device, the execution gets stuck in line #53 of the "file asm_vector.S" (see second screenshot).
The memory error message mentioned in my first post above (see third screenshot) occurs when I'm also adding these two lines of code for configuring an input or output pin:

XGpioPs_SetDirectionPin(&GPIOs, PIN_BTN_1, 0);        // BTN_1 input
XGpioPs_SetOutputEnablePin(&GPIOs, PIN_BTN_1, 0);    // BTN_1 enable

If this is connected to the Zynq board support files / preset, how can I integrate the original files into my project without starting from scratch?

As already mentioned, the code worked fine in the beginning and the error only occurred from time to time. It was possible to control the buttons and LEDs via the GPIO library. After adding some more code, the described errors popped up every time. But removing the new code doesn't solve the problem.

Thanks.

 

[Richm]

The solution is simple. Don't use the buggy Xilinx driver.

Read the TRM for the chip and use Xil_In/Out calls to set the registers directly.

Look in xgpiops_hw.h for definitions of the register address offsets.

[elodg]

I am afraid using direct register access would mask an underlying issue. I haven't seen the PS GPIO driver buggy in any way.

Verify returned pointer for NULL for proper error handling. Verify the device id you are passing. Verify the driver instance structure returned after init for the proper base address.

[Richm]

Can you elaborate as to what kind of underlying issues might  occur when using direct register access for a GPIO?

I've never used the PS GPIO, but the AXI GPIO couldn't be simpler - 1 data and 1 data direction register per channel. In my experience, the Xilinx driver code is way over complicated to the point of being hard to use and debug. More than once I have started with Xilinx example code and then ended up doing what I should have done all along - read the documentation and read/write the registers myself, just like I have done many times in the past with HC11/16s, PICs,  AVRs and ARM microcontrollers.

[gueste]

Thanks for your replies!
Since I'm not that experienced in programming registers directly, I'd prefer to use the drivers, if possible. However, I agree that there seems to be some underlying problem that should be resolved before going further with the project.
Otherwise, it might come up again at a later stage.

I'm already checking the return values for the pointer and the device ID. The listed code was only a part of the original one, just to make it a bit clearer.

Here's a part of the original code:

#define GPIO_DEVICE_ID			XPAR_XGPIOPS_0_DEVICE_ID		// GPIO 0 device ID
XGpioPs GPIOs;

...

Status = setupEmioGPIO(&GPIOs, GPIO_DEVICE_ID);

...

int setupEmioGPIO(XGpioPs *gpioPtr, u16 deviceID) {
	xil_printf("Setting up EMIO GPIOs...\r\n");
	int Status;
	XGpioPs_Config *Config;

	/*
	 * Initialize the GPIO driver so that it's ready to use
	 * Look up the configuration in the config table, then initialize it.
	 */
	Config = XGpioPs_LookupConfig(deviceID);
	if (NULL == Config) {
		xil_printf("ERROR: GPIO setup failed on configuration lookup.\r\n");
		return XST_FAILURE;
	}

	Status = XGpioPs_CfgInitialize(gpioPtr, Config, Config->BaseAddr);
	if (Status != XST_SUCCESS) {
		xil_printf("ERROR: GPIO setup failed during config initialization.\r\n");
		return XST_FAILURE;
	}

	xil_printf("--> EMIO GPIO setup successful.\r\n");
	return XST_SUCCESS;
}//setupEmioGPIO

The configuration seems to be returned correctly, as shown in the attached screenshot. To be able to verify the return value of the LookupConfig() command, I had to comment out the CfgInitialize() line.

Just an idea:
Maybe the error is only contained within the EMIO GPIO library, and switching to the AXI GPIO library as an alternative might help go around the problem?

[elodg]

21 hours ago, Richm said:

Can you elaborate as to what kind of underlying issues might  occur when using direct register access for a GPIO?

I've never used the PS GPIO, but the AXI GPIO couldn't be simpler - 1 data and 1 data direction register per channel. In my experience, the Xilinx driver code is way over complicated to the point of being hard to use and debug. More than once I have started with Xilinx example code and then ended up doing what I should have done all along - read the documentation and read/write the registers myself, just like I have done many times in the past with HC11/16s, PICs,  AVRs and ARM microcontrollers.

There could be an underlying issue with the DDR where this code is running from, or with the cache or interconnect configuration of the Processing System.

@gueste, you could try stepping into the XGpioPs_CfgInitialize function, once you add the debug flags to the domain BSP (-g3 -O0).

Did you try the Hello World and Peripheral Test example applications?