21:31 <c4017w__> Is there a 'global' command to do a mass erase, regardless of flash driver?

21:36 <c4017w__> flash erase_address with length=0 almost does it, but I still need to specify which bank. I guess that's close enough

21:40 <c4017w__> Although it doesn't work out so well for devices with multiple flash banks. Need to call it multiple times

21:56 <zapb__> c4017w__, sector erase 0 last?

21:58 <c4017w__> zapb__, better, but I'd still need to run it for each bank

21:59 <zapb__> Yep, there is no way around it at the moment

22:01 <c4017w__> ok, I'll parse 'flash list' and loop through the banks

22:32 <c4017w__> What was the reasoning behind having a separate working area per bank instead of a single area for the target? In case different banks require a different algorithm loaded? Right now there's some waste having to reload the same algorithm for each bank. Or is it just that the state of the target cannot be guaranteed between calls to .write/.erase etc.?

22:35 <Hawk777> I’m not sure, but for one thing, different banks *could* use different algorithms (in practice, not just in theory) if you have e.g. an algorithm for the internal Flash on an MCU, and a different algorithm for an SPI-connected external Flash which is also mapped as a bank. Also, different operations could use different algorithms (e.g. program uses one, verify uses another0.

22:38 <Hawk777> Also, unless you’ve verified that no execution or memory access commands have been run, the algorithm could have been destroyed (e.g. you run the target and the application writes its own data where the work area lives).

22:39 <c4017w__> Totally makes sense for that use case

22:39 <c4017w__> And your second comment is what I meant about guaranteeing state between calls to .write/.erase etc. It's not really possible

22:40 <c4017w__> ok, I'll live with the tiny overhead :)