Pico-probe Requires Explicit multicore_reset_core1() for Core1 FIFO/ISR Use

[drankinatty]

This is a Raspberry Pi-Pico documentation issue where when describing the use of a 2nd Pico as a debug probe with openocd, there needs to be an explicit note that for multicore use, a system-reset is NOT adequate to reset core1 to allow multicore_launch_core1() to be called without first calling multicore_reset_core1().

This is apparently required due to the state core1 is left in when using a pico-probe setup and flashing with openocd. The effects all pico-examples multicore examples using the FIFO and ISR to communicate between the cores.

An explicit core1 reset and small delay is all that is required to put the pico back in the correct state for a core1 launch, e.g.

  /* must explicitly reset core1 before core1 launch when
   * using 2nd Pico as debug probe with openocd.
   */
  multicore_reset_core1();
  sleep_ms(100);

  multicore_launch_core1(core1_entry);

This note is needed due to the documentation that states a system reset provides a reset for core1 discussing when multicore_reset_core1() is required in the SDK documentation. The multicore_reset_core1() is also required when using a 2nd Pico as a debug probe.

[aallan]

Transferred to pico-feedback because this affects the Picoprobe Appendix in the Getting Started book rather than the online documentation.

[nathan-contino]

@liamfraser does this sound correct and like the best solution to you? I'm hesitant to recommend sleep calls as part of the official API doc, but... if that be the way that it is, it do.

[drankinatty]

The delay may be avoidable. I just found this ensures core1 is reset and ready to launch. It would be worth drilling down to see if there is another workaround. I haven't investigated, but apparently you can also trigger the reset of core1 from the openocd command. Untested, but apparently adding rp2040.core1 arp_reset assert 0 ; rp2040.core0 arp_reset assert 0 ; will reset and reinitialize core1 before core0 allowing normal operation with a pico-probe.

[drankinatty]

Shortest delay I was able to make work was 80 ms. I was not able to make the core resets from openocd work per Openocd one-liner for proper multicore MCU reset?