Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
UCM 7.054, 7.056 (beta)
#11
Whilst it wont help the scenario this time around,  could you make use of the U3 eeprom in the future and change the  upgrade process so it saves a copy to there somehow and use this like a, what would be in PC terms, crash-free bios and be able to recover from in these type scenarios.

Maybe just save the previous firmware to there before it upgrades and any issues if can be reverted back somehow?

Julian

 
Reply
#12
Saving firmware to eeprom will not help if the firmware is corrupted, as you need  working firmware to read the eeprom

For UCM 7.054, once you try to self upgrade, the firmware is corrupted
Reply
#13
Save the previous version to the U3 chip before the new upgrade download starts.   If it fails for any reason then restore from the U3 chip previous version.

Maybe the firmware upgrade cant always do the auto recovery as it doesn\'t necessarily know it is broke; this actual use case in this thread is a good example of that.

But to recover then you could have some ring-fenced code that could recover from U3.  then to initiate the restore retrospectively you just set a Boolean at a memory address X and reset the system and it auto recovers.

That\'s my suggestion anyway.

Julian

 
Reply
#14
[user=876]juwi_uk[/user] wrote:
Quote:Save the previous version to the U3 chip before the new upgrade download starts.   If it fails for any reason then restore from the U3 chip previous version.

Maybe the firmware upgrade cant always do the auto recovery as it doesn\'t necessarily know it is broke; this actual use case in this thread is a good example of that.

But to recover then you could have some ring-fenced code that could recover from U3.  then to initiate the restore retrospectively you just set a Boolean at a memory address X and reset the system and it auto recovers.

That\'s my suggestion anyway.

Julian

The EEPROM fitted is only 32KB.

Reply
#15
Yes, there is also that little problem
Reply
#16
The UCM/GSM4 baseboard has a 256K eeprom (24LC256) in U2 for a start so 32K cannot be the max even if you have in your specific UCM 

That said I\'ve no idea what it would need to be anyway.

J

 

 

 
Reply
#17
[user=876]juwi_uk[/user] wrote:
Quote:The UCM/GSM4 baseboard has a 256K eeprom (24LC256) in U2 for a start so 32K cannot be the max even if you have in your specific UCM 

That said I\'ve no idea what it would need to be anyway.

J
24LC256 is a 256Kbit EEPROM which is 32KB. The UCM firmware file is 256KB.
Reply
#18
UCM 7.056 (beta) fixes the bug in 7.054 (corrupted by self upgrade)


Bugs Fixed

  1. UCM 7.054 cannot be upgraded except  by another UCM

New Features

  1. Implement new UCM command r?TTxxNN query sequential registers where TT = type 0 for Counter, 1 for sensor, xx= starting register no, NN is no of registers. Reply from UCM is r?TTxxNNaaaabbbbccccdddd...... Requires Comfort firmware 7.062
  2. Allows all RS485 modules to be upgraded if the firmware is version 6 including future KP04
Reply
#19
So where does that leave users on 7.054 with just the one UCM as was asked by one user?
Reply
#20
we are still considering the best solution. If there is anyone else who has upgraded to UCM 7.054 please send email to support@cytech.biz or send a PM
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)