Compiling and running application on Zedboard (Pulpissimo)

[meggiman]

Good afternoon,

After several issues I have been able to install the complete SDK and platforms. 

I'm able to compile applications and run them on the rt platform. I'm also able to complete the Vivado implementation of Pulpissimo for the Zedboard. However, I'm still not able to run applications on the Zedboard.

The sequence of steps I carry out are:

1 - Using Vivado Hardware manager I program the device on the Zedboard with the pulpissimo-zedboard.bit configuration file. Everything is fine, the device is configured and led LED0 is on (from the .xdc file and xilinx_pulpissimo.v I identify that this is CSN for SPI channel 1, so it is OK).

2 - source configs/pulpissimo.sh

3 - source configs/fpgas/pulpissimo/genesys2.sh (from the information provided in GitHub there shoulb be also a zedboard.sh script, but this is the only one that can be found)

4 - source sourceme.sh

5 - make clean all

6 - The USB cable that was used to configure the Zynq device is removed from the Zedboard.

7 - The Digilent JTAG-HS2 cable is attached to PMOD A.

8 - openocd -f openocd-zedboard-hs2.cfg

9 - riscv32-unknown-elf-gdb FILENAME

10 - (gdb) target remote localhost:3333

11 - (gdb) load

If within gdb I issue two list commands here is what I get:

1 /*
2 * This example shows how drive a GPIO as an output.
3 */
4
5 #include <stdio.h>
6 #include <rt/rt_api.h>
7 #include <stdint.h>
8
9 #define GPIO 20
10
(gdb) list
11 int __rt_fpga_fc_frequency = 20000000; // e.g. 20000000 for 20MHz;
12 int __rt_fpga_periph_frequency = 10000000; // e.g. 10000000 for 10MHz;
13
14 int main()
15 {
16  unsigned long i;
17
18  // First configure the SPI device
19  rt_spim_conf_t conf;
20  // Get default configuration

Now I want to place a breakpoint at line 19. Therefore what I get is:

(gdb) b 19
No line 19 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) 

Therefore, it seems that something is wrong. If I issue the command 'continue' on gdb I get the message Continuing, and nothing happens.

I have tried the same flow, but issuing a 'source platform-fpga.sh' after step 4, but the result is the same.

Can you identify if something is missing or wrong in the steps I'm following? Any help will be appreciated.

In order to check if the program is being executed properly by Pulpissimo on the Zedboard I'm trying to turn OFF LED0 by changing the value of the CSN signal of SPI channel 1 that is mapped onto this LED, but without success until now.

Best regards,

Manuel

Hi Manuel,

Could you please try to set a breakpoint on _start (b _start in GDB)? This is the entry point of the binary and the first instruction that should be executed. Also what options did you provide to GCC? In order to be able to debug a program with sourcecode line information you should compile your programm with the gcc -g flag. Have a look at the following application Makefile as an example:

Code:

PULP_APP = test
PULP_APP_FC_SRCS = test.c
PULP_APP_HOST_SRCS = test.c
PULP_CFLAGS = -O0 -g

include $(PULP_SDK_HOME)/install/rules/pulp_rt.mk

The -O0 disable optimization which sometimes makes it easier to debug. 

Also, I assume you made sure that openocd correctly connects to the FPGA?


Greetings,
another Manuel :-)

Hi (another :-)) Manuel,

First of all, thank you very much for your prompt answer. Here are the contents of the Makefile I'm using:

PULP_APP = test
PULP_APP_FC_SRCS = test.c
PULP_CFLAGS = -O3 -g

include $(PULP_SDK_HOME)/install/rules/pulp_rt.mk

As you can see, the option -g is already included. Regarding opencd, when I start it I can see that is waiting for connections coming from gdb through  the 3333 port. When I start gdb and set the proper target I can see that openced accepts the connection. Is there anything else I should do to check that opencd is working properly?

Best regards,

Manuel

Could you please share the output of OpenOCD when you start it up? In some scenarios, openocd might start the GDB server even though there was an issue while connecting to the core. So all of the output should be checked carefully. Also, did you try to set the breakpoint at _start or __rt_init with the -O0 -g option?

Greetings,
Manuel