[41CL] is it recommended to unplug module images during an upgrade?

[cdmackay]

potentially silly question…

I've been happily upgrading my 41CL over the two years I've had it, but only today has it occurred to me to wonder whether it's wise to upgrade module images that are currently plugged?

i.e. if I see in advance that a module image I currenty have plugged, is doing to be upgraded, should i be unplugging it before starting the upgrade?

If the MMU is currently mapping a page to an area of flash, and that area of flash gets overwritten, is that bad?

Or is it all OK, on the grounds that no code from said module is going to be running during the upgrade? I wondered about polling, etc…?

Am I now worrying over nothing?

[Monte Dalrymple]

There is no problem with leaving any image (even the 41CL Update Functions itself or even the OS) plugged in during an automatic update. The FLUPD function never returns to the OS until the update is done so no polling points will be read until the update is done. The same is true for the P8UPD function. If you are doing an update page-by-page manually it will be required to unplug pages being updated because the Flash will be erased as a separate step and that WILL cause problems when polling points are read at the end of a function. No way around that.

[cdmackay]

wonderful! thanks for the detailed explanation, Monte.

[cdmackay]

Whilst we're talking about FLUPD, I'd been wondering…

Is there scope for a slight performance enhancement in FLUPD, during the CPY phase that copies the 8 pre-update flash sector pages to RAM buffer 0x810, by only copying the pages that are not being updated?

i.e. there seems no point including pages that are going to be updated, in the CPY to 0x810, only for them to be immediately overwritten by the IMP import to 0x810 from the PC?

The AUTOVFY CRC would still work, since that is done after the IMP.

would that be worth doing?

[Sylvain Cote]

With exception of the Flash first/last block, all the other Flash blocks have a size of 64KB.
Also, one 4K word (10 bits) module becomes a 8KB in the 41CL world.
This means that one 64KB Flash block can contains 8 modules x 4K word.
Finally, a flash block cannot be partially erased.

So that is why the update must do this logic

1. copy a 64KB flash block into RAM (0x810 ... 0x817)
2. update the modules in RAM that need to be updated
3. erase the 64KB flash block
4. copy RAM (0x810 ... 0x817) to the 64KB flash block
   

Sylvain

[cdmackay]

thanks very much Sylvain.

Ah, so you simply can't read just one page's 8KB from a flash sector, you have to read the whole 64KB sector? i knew it had to be written as one, but thought that reading it might be more fine-grained.

I thought I had noticed the RAM locations shown changing "CPY 810–817", as it does the copy, so had assumed that it was actually copying them 8KB at a time, hence my question: I'd thought that stage 1 could skip copying the per-page 8KB parts of the flash sector, for the pages that are going to be updated.

I get it now

thanks!

[Sylvain Cote]

(03-25-2021 06:44 PM)cdmackay Wrote:  Ah, so you simply can't read just one page's 8KB from a flash sector, you have to read the whole 64KB sector?

No, you can read 1 byte if you want, the problem is not the reading from Flash part is the writing to Flash part.

Back to basic, when you are erasing a Flash sector, you are in reality setting all the bits in the sector to 1.
After that, you can drop 1 bit to 0 but you cannot raise it back to 1 without erasing the whole Flash sector again.

In our case the Flash sector has a size of 64KB. (putting the first/last sector exception aside for the moment here)
For our discussion let say that it contains 8 modules and of those only 1 is outdated.
It is impossible to only update the outdated module (8KB) directly in Flash because the Flash chip is only able to erase the whole sector (64KB) not part of it (8KB).
That is why we need to copy the whole sector from Flash to RAM,
then update the outdated modules in RAM, (8KB per outdated module)
erase the whole 64KB Flash sector (if we had not copied the sector in RAM previously we will have loose the other 7 modules at this step)
then we copy the update sector from RAM to Flash. (the whole 64KB)

I hope it is more clearer.

Sylvain

[cdmackay]

thank you Sylvain, yes, that is clear, and I was aware of it.

I fear I am doing a bad job of explaining my point, sorry.

My point relates to the flash sector pages for modules that are being updated.

I am asking why we need to copy those pages from flash to RAM, only for them to be immediately overwritten in RAM by the new module image that we import from the PC.

For example, for a flash sector that has 1 outdated module image…

As you said, the current process is:

1. copy a 64KB flash block into RAM (0x810 ... 0x817)
2. update the modules in RAM that need to be updated
3. erase the 64KB flash block
4. copy RAM (0x810 ... 0x817) to the 64KB flash block

In step 1, we copy the entire 64KB sector from flash to RAM. That equates to all eight 8KB modules in that sector.

In step 2, we update the 8KB RAM page for the single module that is being updated. So that particular 8KB that we read from flash has been immediately overwritten by the 8KB module image we imported from the PC. So we didn't need to read that particular 8KB from flash at all.

My suggestion was a change to step 1 (only); changes in italics:

1. copy part of a 64KB flash block into RAM (0x810 ... 0x817). Copy only 8KB chunks for pages that are not being updated. Do not copy the 8KB chunks for pages that are about to be updated (since they will be immediately overwritten in RAM).
2. update the modules in RAM that need to be updated
3. erase the 64KB flash block
4. copy RAM (0x810 ... 0x817) to the 64KB flash block

Initially, I thought you were saying that's no good because we can only read 64KB at a time from flash. But no, I had misunderstood that, and you confirm that we can read at a byte granularity.

If the above is valid, then step 1 would be slightly faster. If several modules of that sector were being updated, it would be faster still. Perhaps it's not a worthwhile saving, given the effort involved, but I wondered.


I am probably missing something, but I don't yet see what it is

thanks for reading!

[Sylvain Cote]

Ha! Ha!
Now I understand your initial question.
My limited understanding of English is not helping here, but eventually we get there.

For sure, this is an optimization that could be implemented by Monte in the update ROM, but only him can answer that one.
To my knowledge there is no free bytes left in the update ROM do add that kind of optimization.
We will have to wait for his answer on this.

Sylvain

[cdmackay]

ah great, thanks Sylvain. Good point about code space.

thanks again.

[Monte Dalrymple]

(03-25-2021 03:12 PM)cdmackay Wrote:  Whilst we're talking about FLUPD, I'd been wondering…

Is there scope for a slight performance enhancement in FLUPD, during the CPY phase that copies the 8 pre-update flash sector pages to RAM buffer 0x810, by only copying the pages that are not being updated?

i.e. there seems no point including pages that are going to be updated, in the CPY to 0x810, only for them to be immediately overwritten by the IMP import to 0x810 from the PC?

The AUTOVFY CRC would still work, since that is done after the IMP.

would that be worth doing?

This feature was on my original list of requirements, but I ran out of space. Currently there are only half a dozen unused locations available in the rom image.

[cdmackay]

thanks Monte! And Sylvain too.