RP2040: is cross-core synchronization unnecessary in existing flash operations?

[rdon-key]

While reading the existing RP2040 flash code paths in machine_rp2040_rom.go, I noticed that flash_range_write, flash_erase_blocks, and flash_do_cmd disable interrupts on the calling core and perform XIP-related handling, but I do not see any explicit stopping or synchronization of the other core.

From this code, I can see handling such as:

• disabling interrupts on the calling core
• connecting internal flash
• exiting XIP mode
• flushing cache
• restoring XIP state afterwards

However, I do not see anything here that explicitly stops the other core or synchronizes with it.

So I wanted to ask:

Is cross-core synchronization considered unnecessary for these existing RP2040 flash operations?

Or is cross-core safety expected to be handled somewhere else?

Relevant code paths include:

• flash_range_write
• flash_erase_blocks
• flash_do_cmd

From the current code, it is hard to tell whether the lack of explicit cross-core handling is intentional or simply not implemented here.

[rdon-key]

Update: confirmed this is not just a code-reading question — it causes a hard hang on real hardware

After reviewing the code paths, I built a small reproducer to check whether the absence of cross-core synchronization actually causes problems in practice. It does.

Summary

With -scheduler=cores on RP2040 (Pico), when a goroutine is actively running on Core 1 and repeatedly reading from a flash-resident const array larger than the 16 KB XIP cache, calling machine.Flash.WriteAt from Core 0 hangs indefinitely.

flash write start is printed, but flash write done never appears, and the device becomes completely unresponsive (no further serial output, no forward progress).

With -scheduler=tasks, the same program completes all writes successfully, but only because NumCPU == 1 and no concurrent flash access occurs.

Environment

• TinyGo: 0.41.0 (Go 1.24.13, LLVM 20.1.1)
• Target: pico (RP2040)
• Host: Windows / MinGW

Observed behavior

-scheduler=cores (hangs)

NumCPU: 2
main core: 0
FlashDataStart: 0x10014000
FlashDataEnd: 0x10200000
selected flash abs offset: 0x101ff000
selected flash rel offset: 0x001eb000
round: 0 main core: 0 worker core: 1 stage(before): 2 heartbeat(before): 38 checksum: 616864
flash write start
<hang — no further output, device unresponsive>

At the moment of the hang:

• the worker is running on Core 1 (worker core: 1)
• it is inside the flash access loop (stage: 2)
• it is making progress (heartbeat increasing, checksum != 0)

Core 0 then enters Flash.WriteAt, and the entire system stops.

-scheduler=tasks (completes normally)

NumCPU: 1
worker core: 99
stage(before): 0
heartbeat(before): 0
flash write start
flash write done: 4096
...
test finished

Here the worker goroutine is not running concurrently, so no flash access happens on another core.

Key condition

The worker reads from a ~64 KB flash-resident const array, which exceeds the 16 KB XIP cache on RP2040. This ensures sustained flash reads from Core 1.

Interpretation

The current implementation:

• disables interrupts on the calling core
• performs XIP transition handling (exit XIP, reconnect, flush cache, etc.)

but does not prevent the other core from accessing flash.

On RP2040 this is unsafe. If Core 1 continues to fetch instructions or read data from flash while Core 0 is performing a flash operation, the system can stall.

This behavior matches the known requirement in pico-sdk, where flash operations must exclude the other core (e.g. flash_safe_execute / multicore_lockout_*).

Conclusion

This is not just theoretical — in practice, the lack of cross-core synchronization during flash operations can cause a hard hang when the multicore scheduler is enabled.

---

Reproducer

main.go

package main

import (
	"machine"
	"runtime"
	"sync/atomic"
	"time"
	"unsafe"
)

const maxRounds uint32 = 3
const writeSize = 4096

const sioCPUID = uintptr(0xd0000000)

func coreID() uint32 {
	return *(*uint32)(unsafe.Pointer(sioCPUID))
}

func alignDown(v uintptr, align uintptr) uintptr {
	return v & ^(align - 1)
}

func safeFlashOffset(round uint32) int64 {
	start := uintptr(machine.FlashDataStart())
	end := uintptr(machine.FlashDataEnd())

	println("FlashDataStart:", start)
	println("FlashDataEnd:", end)
	println("FlashDataSize:", end-start)

	if end <= start || end-start < writeSize {
		println("not enough writable flash data area")
		for {
		}
	}

	lastAligned := alignDown(end-uintptr(writeSize), uintptr(writeSize))
	available := (lastAligned - start) / uintptr(writeSize) + 1

	rotated := uintptr(round) % available
	absOffset := lastAligned - rotated*uintptr(writeSize)
	relOffset := absOffset - start

	println("selected flash abs offset:", absOffset)
	println("selected flash rel offset:", relOffset)

	return int64(relOffset)
}

var buf [writeSize]byte

var workerCore uint32 = 99
var heartbeat uint32
var checksum uint32
var stage uint32
var workerDone uint32 // 0 = continue, 1 = stop request, 2 = stopped

// Exactly 256 bytes: 4 lines x 64 chars.
const chunk256 = "" +
	"0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" +
	"fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210" +
	"00112233445566778899aabbccddeeffffeeddccbbaa99887766554433221100" +
	"rp2040xipcacheflashworkerrandomaccesstestdataAAAAAAAAAAAAAAAAAAA"

// 4096 bytes (4 KB).
const block4k = chunk256 + chunk256 + chunk256 + chunk256 +
	chunk256 + chunk256 + chunk256 + chunk256 +
	chunk256 + chunk256 + chunk256 + chunk256 +
	chunk256 + chunk256 + chunk256 + chunk256

// 65536 bytes (64 KB). Large enough to overflow the 16 KB XIP cache on RP2040.
const flashData = block4k + block4k + block4k + block4k +
	block4k + block4k + block4k + block4k +
	block4k + block4k + block4k + block4k +
	block4k + block4k + block4k + block4k

func worker() {
	led := machine.LED
	led.Configure(machine.PinConfig{Mode: machine.PinOutput})

	atomic.StoreUint32(&workerCore, coreID())
	atomic.StoreUint32(&stage, 1)

	x := uint32(0x12345678)
	sum := uint32(0)

	for atomic.LoadUint32(&workerDone) == 0 {
		atomic.StoreUint32(&stage, 2)

		for n := 0; n < 8192; n++ {
			x = x*1664525 + 1013904223
			i := int(x % uint32(len(flashData)))
			sum += uint32(flashData[i])

			if n&255 == 0 {
				atomic.AddUint32(&heartbeat, 1)
			}
			if n == 4096 {
				atomic.StoreUint32(&stage, 4)
			}
		}

		atomic.StoreUint32(&checksum, sum)
		atomic.StoreUint32(&workerCore, coreID())
		atomic.StoreUint32(&stage, 3)

		led.Set((sum & 0x800000) != 0)
	}

	atomic.StoreUint32(&stage, 5)
	atomic.StoreUint32(&workerDone, 2)
}

func main() {
	time.Sleep(5 * time.Second)
	println("start")
	println("NumCPU:", runtime.NumCPU())
	println("main core:", coreID())
	println("flashData size:", len(flashData))
	println("max rounds:", maxRounds)

	if len(chunk256) != 256 {
		println("WARN: chunk256 size unexpected:", len(chunk256))
	}
	if len(flashData) != 65536 {
		println("WARN: flashData size unexpected:", len(flashData))
	}

	for i := range buf {
		buf[i] = byte(i ^ 0x5a)
	}

	go worker()

	for round := uint32(0); round < maxRounds; round++ {
		flashOffset := safeFlashOffset(round)

		hbBefore := atomic.LoadUint32(&heartbeat)
		sum := atomic.LoadUint32(&checksum)
		wc := atomic.LoadUint32(&workerCore)
		stBefore := atomic.LoadUint32(&stage)

		println("round:", round,
			"main core:", coreID(),
			"worker core:", wc,
			"stage(before):", stBefore,
			"heartbeat(before):", hbBefore,
			"checksum:", sum)

		println("flash write start")
		n, err := machine.Flash.WriteAt(buf[:], flashOffset)
		if err != nil {
			println("flash write error:", err.Error())
		} else {
			println("flash write done:", n)
		}

		hbAfter := atomic.LoadUint32(&heartbeat)
		stAfter := atomic.LoadUint32(&stage)
		println("after write -> stage:", stAfter,
			"heartbeat(after):", hbAfter,
			"heartbeat delta:", hbAfter-hbBefore)

		if hbAfter == hbBefore {
			println("WARN: worker may be stalled (no heartbeat progress)")
		}
	}

	println("requesting worker stop")
	atomic.StoreUint32(&workerDone, 1)
	for atomic.LoadUint32(&workerDone) != 2 {
	}
	println("worker final stage:", atomic.LoadUint32(&stage),
		"final heartbeat:", atomic.LoadUint32(&heartbeat),
		"main core:", coreID())

	println("test finished")

	for {
	}
}

---

Build commands

tinygo flash -target=pico -scheduler=cores -monitor main.go   # hangs
tinygo flash -target=pico -scheduler=tasks -monitor main.go   # completes (NumCPU == 1, no concurrent flash access)

[aykevl]

Yes, sounds like a bug to me.

There may be multiple ways to fix this, for example:

• Use the same mechanism as GC to pause the other core.
• Set a flag somewhere, wait for the other core to sleep before doing the flash operation.

Not sure which is easier, both will require some low level fiddling with the scheduler.

[rdon-key]

@aykevl
Thank you for your comment. I’ll start by preparing an RP2040-only fix and opening a PR.