Hi Bob
Welcome to the forum and thanks for your ideas.
I did do as you suggested, but only after checking the clocking details because my main concern was with 'frying' the chip by using false clock settings when programming. It turned out (as I now believe to be the true case) that the internal 4MHz RC oscillator was being used rather than the external 12MHz crystal, which would have meant some overprogramming - however with the correct settings it didn't make any noticable difference in the speed.
The measurements that I made showed then the following situation:
- Check of new code and CRC-16 took 2.5s for 55k new code size
- Delete of old code took 0.6s
- Programming of new code took 3s (including copying it)
- Check of newly programmed code and CRC-16 took 3s
- delete of backup of new code took 0.5s
Therefore the FLASH operations were not that significant, but rather the processing speed (4MHz and without MAM acceleration) was the bottle-neck.
Since the project code supports PLL configurations, starting from either non-configured or already connected, I decided to set this to max. when doing the checking and copying functions. Without optimised MAM settings it then took about 2s. With optimised MAM (partially-active) it was then about 1.5s.
During the process I did find a problem with the optimisation of the GCC compiler causing PLL setup register access order to be inverted at one critical location, which resulted in some strange effects during first tests, but ensuring that PLLCON is specified as volatile solved it.
The result is that firmware upgrades are now really QUICK!! Between pushing the upload button in the browser and seeing the new code communicating there is a delay of around 4s (including a 2s pause before the board actually commands the reset for the copy). I can certainly live with that!!!
Best regards
Mark