OpenOCD "load_image" also sets the chip running?

[nwf]

Not really understanding what's going on here, but... the most visible problem is that util/mem_helper.sh often fails the verification it tries to do and the chip is clearly running while that's happening. I'm a little surprised not to see a reset run command being given to OpenOCD.

Trying to minimize things a bit, I've observed the following:

1. running

   openocd -f .../sonata-system/util/sonata-openocd-cfg.tcl -c halt -c exit
   

   indeed halts the chip and leaves it that way, even after OpenOCD exits, so presumably exit does not imply reset run.
2. running

   openocd -f .../sonata-system/util/sonata-openocd-cfg.tcl -c "load_image .../top_compartment 0" -c "sleep 5000" -c exit
   

   loads the image in question and sets the chip in motion at the start of the 5 second timeout, suggesting that load_image does imply reset run, though I don't think it's supposed to.
3. running

   openocd -f .../sonata-system/util/sonata-openocd-cfg.tcl -c "load_image .../top_compartment 0" -c halt -c "sleep 5000" -c exit
   

   does not halt the CPU after load_image. Perhaps some part of the system believes it to be already halted and so does nothing, or perhaps the target is claiming to be halted when it is not.

The upshot of this is that if I remove the verify_image commands from util/mem_helper.sh, I get much better success rate loading in programs, but this is... disconcerting. Please advise and please let me know what more I can do or test to be useful.

[marnovandermaas]

Thanks for sharing this. Halting and exiting is not supported in the current debug setup on Sonata. It is essentially a fancy way of writing to the bus. The way that we "halt" the core is by resetting it any time the debug module writes to the bus. The main reason we designed it this way is that we didn't have a CHERIoT-enabled debug ROM available when we were doing bring-up.

[marnovandermaas]

Just for reference to anyone else stumbling on this issue, the openOCD flow on Sonata is very much an advanced feature and not the main way we designed Sonata to be used. Most people should just use the UF2 method to load new programs on the board. As far as I understand nwf is wanting to use openOCD to avoid writing too many times to flash.

[nwf]

AFAICT this is due to

sonata-system/rtl/system/sonata_system.sv

Lines 264 to 277 in e7088a6

	// Hold the core in reset for a period after debug monitor accesses,
	// in anticipation of further accesses whilst downloading completes.
	//
	// Release the code after 2^21 cycles, which will be ca. 20-100ms for
	// typical system clock frequencies.
	logic [20:0] dbg_release_cnt;
	wire dbg_release_core = &dbg_release_cnt;
	always_ff @(posedge clk_sys_i or negedge rst_sys_ni) begin
	if (!rst_sys_ni) begin
	dbg_release_cnt <= {21{1'b1}};
	end else if (host_req[DbgHost] | ~dbg_release_core) begin
	dbg_release_cnt <= host_req[DbgHost] ? '0 : (dbg_release_cnt + 1);
	end
	end

: the chip comes out of reset by itself after the debugger accesses memory?

[marnovandermaas]

Yes, exactly. The core is held in reset for a while after the debugger has written to the bus. The only way openOCD and/or the debug module can keep the core in reset is by keep on writing stuff to the bus. This allows you to do a load_image and after that whole image is written to SRAM, the core comes out of reset and executes the thing you've just written. This is a developer feature for advanced users only.