Reset Error When Programming kasli_soc Using local_run.sh #283

Closed
opened 2024-01-02 18:53:48 +08:00 by JonahFoley · 2 comments

I am performing gateware development of ARTIQ and now wish to test my changes on the target platform, Kasli SoC. I have managed to build both the gateware and the firmware for the target device using the supplied makefiles, however I am struggling to program the board.

My configuration is a PC connected to the Kasli SoC board via micro-usb, with a direct connection to the board via an ethernet cable. To program it I enter the nix develop shell and invoke the local_run.sh script, however encounter the error:

(nix:artiq-zynq-dev-shell-env) [jfoley@localhost artiq-zynq]$ ./local_run.sh 
Open On-Chip Debugger 0.11.0
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Zynq CPU1.
Info : clock speed 1000 kHz
Info : JTAG tap: zynq.tap tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: zynq.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Info : zynq.cpu.0: hardware has 6 breakpoints, 4 watchpoints
Info : zynq.cpu.1: hardware has 6 breakpoints, 4 watchpoints
Info : zynq.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Info : zynq.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT
Info : starting gdb server for zynq.cpu.0 on 3333
Info : Listening on port 3333 for gdb connections
Info : JTAG tap: zynq.tap tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1)
Info : JTAG tap: zynq.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4)
Warn : zynq.cpu.0: ran after reset and before halt ...
Info : zynq.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41
Error: timeout waiting for DSCR bit change
Error: Error waiting for halt

Investigating this further, I see the error comes from the invocation of openocd with the kasli_soc.cfg file of the directory $OPENOCD_ZYNQ. I.e. the command: openocd -f kasli_soc.cfg produces the same error.

This error can be attributed to the reset halt command within kasli_soc.cfg:

ftdi_layout_signal nSRST -oe 0x0004
reset_config srst_only srst_open_drain
adapter srst pulse_width 250
adapter srst delay 400

source ./common.cfg

reset halt # Causes ERROR 

I am wondering how to approach debugging or resolving this issue. I can see the reset command is configured with the previous reset_config ... etc. commands. Could modifying these delays fix my issue, or is there a potential error with my configuration.

I have attached the full logs from running the command with the debug flag set for reference.

I am performing gateware development of ARTIQ and now wish to test my changes on the target platform, Kasli SoC. I have managed to build both the gateware and the firmware for the target device using the supplied makefiles, however I am struggling to program the board. My configuration is a PC connected to the Kasli SoC board via micro-usb, with a direct connection to the board via an ethernet cable. To program it I enter the `nix develop` shell and invoke the `local_run.sh` script, however encounter the error: ``` (nix:artiq-zynq-dev-shell-env) [jfoley@localhost artiq-zynq]$ ./local_run.sh Open On-Chip Debugger 0.11.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Zynq CPU1. Info : clock speed 1000 kHz Info : JTAG tap: zynq.tap tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1) Info : JTAG tap: zynq.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4) Info : zynq.cpu.0: hardware has 6 breakpoints, 4 watchpoints Info : zynq.cpu.1: hardware has 6 breakpoints, 4 watchpoints Info : zynq.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41 Info : zynq.cpu.1: MPIDR level2 0, cluster 0, core 1, multi core, no SMT Info : starting gdb server for zynq.cpu.0 on 3333 Info : Listening on port 3333 for gdb connections Info : JTAG tap: zynq.tap tap/device found: 0x1372c093 (mfg: 0x049 (Xilinx), part: 0x372c, ver: 0x1) Info : JTAG tap: zynq.dap tap/device found: 0x4ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x4) Warn : zynq.cpu.0: ran after reset and before halt ... Info : zynq.cpu.1 rev 0, partnum c09, arch f, variant 3, implementor 41 Error: timeout waiting for DSCR bit change Error: Error waiting for halt ``` Investigating this further, I see the error comes from the invocation of `openocd` with the `kasli_soc.cfg` file of the directory `$OPENOCD_ZYNQ`. I.e. the command: `openocd -f kasli_soc.cfg` produces the same error. This error can be attributed to the `reset halt` command within `kasli_soc.cfg`: ``` ftdi_layout_signal nSRST -oe 0x0004 reset_config srst_only srst_open_drain adapter srst pulse_width 250 adapter srst delay 400 source ./common.cfg reset halt # Causes ERROR ``` I am wondering how to approach debugging or resolving this issue. I can see the reset command is configured with the previous `reset_config ...` etc. commands. Could modifying these delays fix my issue, or is there a potential error with my configuration. I have attached the full logs from running the command with the debug flag set for reference.
Related I assume https://github.com/m-labs/artiq/issues/2250

Resolved via https://github.com/sinara-hw/Kasli-SOC/wiki/compiling-and-flashing. You must:

  1. Set the jumper on the Kasli SoC board to PS_POR_B
  2. Set the Kasli SoC DIP switches to 'JTAG'
  3. run kasli_soc_por.py script between successive programming runs
Resolved via https://github.com/sinara-hw/Kasli-SOC/wiki/compiling-and-flashing. You must: 1. Set the jumper on the Kasli SoC board to PS_POR_B 2. Set the Kasli SoC DIP switches to 'JTAG' 3. run `kasli_soc_por.py` script between successive programming runs
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/artiq-zynq#283
There is no content yet.