multicore flash write with interrupts enabled?

[myklemykle]

Hi,

I can see in LittleFSImpl::lfs_flash_prog that during a flash write the writing core pauses the other core and disables interrupts. I get why: you can't have any reads from flash during a write, including through the XIP cache, or there's corruption.

But in my current project I have an ISR on core1, a not_in_flash_func, that refills an audio buffer. It's just copying samples between buffers in RAM and doing math on them. It's not calling any other functions. It really should not be touching flash. So it ought to be fine to let this run during a flash write, right? Because currently I get a nasty audio glitch during flash writes when core1 is paused.

It seems to me that if my ISR is flash-safe, and my loop1() is also pinned in RAM, and it runs an empty loop during the write, then it could be safe to write flash without idling the other core. Does that seem plausible? Or what else could go wrong?

I can see a hacky way of testing this, where I modify LittleFS.cp to not call rp2040.idleOtherCore(). But is there any more "correct" way to try to do it?

Thx!

[earlephilhower]

There's not a "correct" way since you're basically rolling your own at this point.

If you guarantee the other core isn't going to need flash (you can use ROM or routines in RAM) then you can hack out that freeze. Be careful, though, of other possible interrupt sources and any use of standard library routines (even if you're not explicitly calling them...). I think I've put all my ISR routines in RAM in the core, but if you do find something firing that's in flash, a PR would be appreciated. Good luck!

[myklemykle]

Thanks for the advice. I had a swing at this last week, returning to it now. I subclassed LittleFSImpl to make DangerFSImpl, where i just commented out those idle/resume calls:

	// override one method in the little fs implementation ....
	
	class DangerFSImpl : public littlefs_impl::LittleFSImpl {
		public:

			DangerFSImpl(uint8_t *start, uint32_t size, uint32_t pageSize, uint32_t blockSize, uint32_t maxOpenFds):
				LittleFSImpl(start, size, pageSize, blockSize, maxOpenFds)
				{
				_lfs_cfg.prog = lfs_flash_prog;
				};

			static int lfs_flash_prog(const struct lfs_config *c, lfs_block_t block, lfs_off_t off, const void *buffer, lfs_size_t size) {
				DangerFSImpl *me = reinterpret_cast<DangerFSImpl*>(c->context);
				uint8_t *addr = me->_start + (block * me->_blockSize) + off;
				noInterrupts();
				//rp2040.idleOtherCore();

				//Dbg_printf("WRITE: %p, $d\n", (intptr_t)addr - (intptr_t)XIP_BASE, size);

				flash_range_program((intptr_t)addr - (intptr_t)XIP_BASE, (const uint8_t *)buffer, size);

				//rp2040.resumeOtherCore();
				interrupts();
				return 0;
			};

	};

Alas, pico hangs when I try to write a file with this. Now I'm trying to work out why.

I tried leaving loop1() completely empty, that didn't change anything.

Then I turned off my ISR on core 1. At that point all I'm running on core 1 is an empty loop1() method. Pico still hangs.

I replaced the empty loop1() method with a wait loop that never ends, so that loop1() never returns. Pico still hangs!

So I wonder: does arduino-pico run some other ISRs on core1 that might be trying to read flash? It's a little bit hard for me to grep the source and know what parts of it will be run on core0 vs core1. But the only irq_set_* call I found that's not specifically about some peripheral is this one in RP2040Support.h, and I don't really get what it does:

    void registerCore() {
        if (!__isFreeRTOS) {
            multicore_fifo_clear_irq();
            irq_set_exclusive_handler(SIO_IRQ_PROC0 + get_core_num(), _irq);
            irq_set_enabled(SIO_IRQ_PROC0 + get_core_num(), true);
        }
        // FreeRTOS port.c will handle the IRQ hooking
    }

[earlephilhower]

If you don't have a setup1 or loop1 then absolutely nothing will run on Core 1. It won't even be started. Everything run by the core runs on Core 0 (unless you start it in your own app from Core 1). Your noInterrupts will disable IRQs only on the core it executes on, not on both, BTW.

Remember, you need everything running on the other core to be in RAM. You need to decorate the functions and not use any standard library routines because those live in flash (sprintf, malloc, strlen, memcpy, etc.). No STL, those templates are not going to end up in RAM. No calling any Arduino functions like digitalWrite, either, those are in flash. You can't be reading flash constants/strings/etc. either, same reason as code.

Even an empty void loop1() {} will be in flash. Even if you decorate it properly, there's a while (true) loop1() loop run in main.cpp which will also be in flash, so you can't even exit loop safely. (Same for both cores, obviously).

[earlephilhower]

Actually, if you're trying to write from Core1, even USB will need to be commented out. The USB interrupt handler may be in RAM, but it does all the callbacks in flash because they're very large.

You may want to just skip the Arduino core and start writing your app for the bare metal w/the SDK so you can remove USB and all other potential gotchas. There's also a linker option there to let you build an app to run entirely from RAM (but you are obviously limited to a very small app and have very little free RAM for it to use).

[myklemykle]

Writing from core 0, thankfully ...

[myklemykle]

OK, much to probably nobody's surprise I had a bug in my own code which was causing some hangs as well. (I had some debug output in lfs_flash_prog() and it appears you can sometimes call Serial.print() while interrupts are off, but other times it will block forever.)

Having un-snafu'd all that ... DangerFS works now! I should probably stress-test it a bit harder, tho I might burn out the flash on a Feather board if I want to do really significant testing.

However, after all that ... I'm still getting the stupid audio glitch during write that was the cause of this whole digression! Something still prevents the audio ISR on core 1 from firing during the flash write executing on core 0. Puzzling.