Comfort Automation/ Security System Forums > Products > UCM > UCM Firmware > UCM 7.054, 7.056 (beta) |
Comfort Automation/ Security System Forums > Products > UCM > UCM Firmware > UCM 7.054, 7.056 (beta) |
| Moderated by: ident | ||
| Author | Post | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
ident Administrator 
|
The beta firmware 7 .054 has the following changes
BUG UCM 7.054 will not be able tp upgrade its own firmware. Please do NOT upgrade to UCM 7.054 and if you have done so, do not try to upgrade (or downgrade) the firmware until further instrutions Last edited on Wednesday Aug 27th, 2014 04:32 pm by ident |
|||||||||
|
ident Administrator
|
We have just detected a serious bug in UCM 7.054 (beta) If the UCM is upgraded to this firmware, the UCM will NOT be able to upgrade its own firmware again Do NOT upgrade to UCM 7.054 and if you have done so, Do NOT try to upgrade firmware any further We will check if it is OK to upgrade the UCM firmware via another UCM. More information will be provided The beta firmware has been removed from the server Last edited on Wednesday Aug 27th, 2014 04:33 pm by ident |
|||||||||
|
juwi_uk Member 
|
Yep I trashed the UCM/Eth3 on my test rig! Presume it cant connect anymore it the issue right? Julian |
|||||||||
|
slychiu Administrator 
|
The ucm with 7.054 will work until you try to upgrade it again, so do not upgrade it by the normal method You can use another ucm with the firmware upgrade cable to upgrade the ucm 7.054 |
|||||||||
|
juwi_uk Member
|
Unless that other UCM is also on 7.054? What happens then? |
|||||||||
|
slychiu Administrator
|
No problem The 7.054 only has a problem when it has to upgrade its own firmware It has no problem with uograding another ucm |
|||||||||
|
slychiu Administrator
|
No problem The 7.054 only has a problem when it has to upgrade its own firmware It has no problem with uograding another ucm |
|||||||||
|
juwi_uk Member
|
Yes I just reverted both my 7.054 UCMs back to 7.049 using the programme cable method without a hitch! Phew! I guess you have to slip in these problematic upgrades if only just to remind us once, every so often, as to how lucky we are normally not to have to faff with the programming method anymore. I even had to read the manual as so long since I've done one!  Julian |
|||||||||
|
cc_uk Member
|
Is there likely to be a recovery for those of us with one UCM only on 7.054? |
|||||||||
|
ident Administrator
|
Do you have another UCM by any chance? We are looking at how to solve it. but do not try to upgrade the ucm firmware using the same UCM. Using another UCM should be no problem |
|||||||||
|
juwi_uk Member
|
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 |
|||||||||
|
ident Administrator
|
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 |
|||||||||
|
juwi_uk Member
|
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 |
|||||||||
|
tman Comfort Distributors
|
juwi_uk wrote: 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. The EEPROM fitted is only 32KB. |
|||||||||
|
ident Administrator
|
Yes, there is also that little problem |
|||||||||
|
juwi_uk Member
|
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 |
|||||||||
|
tman Comfort Distributors
|
juwi_uk wrote: 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 24LC256 is a 256Kbit EEPROM which is 32KB. The UCM firmware file is 256KB. |
|||||||||
|
ident Administrator
|
UCM 7.056 (beta) fixes the bug in 7.054 (corrupted by self upgrade) Bugs Fixed
New Features
|
|||||||||
|
juwi_uk Member
|
So where does that leave users on 7.054 with just the one UCM as was asked by one user? |
|||||||||
|
ident Administrator
|
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 |
|||||||||
|
juwi_uk Member
|
Oh my mistake. I understand the eeprom I mentioned is 256K bits not bytes. That said couldn't you save part of the firmware to U3 (ie the download/upload code part), then if you had similar in future you could get the customer to set memory address xxxx as 1 and restart and it would at least allow a new firmware to be uploaded. Last edited on Saturday Aug 30th, 2014 12:15 pm by juwi_uk |
|||||||||
|
ident Administrator
|
Unfortunately that solution would not work in the current situation, as the firmware will not even operate so it would not be able to read the eeprom |
|||||||||
|
tman Comfort Distributors
|
juwi_uk wrote: Oh my mistake. I understand the eeprom I mentioned is 256K bits not bytes. A neater solution for the general UCM would be to have just enough code inside a protected bootloader that never gets reflashed to accept a UCM firmware over the USB/Ethernet/RS232 port. The PC interface is just serial from the point of view of the UCM uC so the actual module attached doesn't affect anything. The bootloader would only be capable of loading a new firmware and running whatever is in flash. You'd trigger recovery mode by doing something unusual like plugging in the UCM whilst some odd combination of jumpers is shorted or holding down a button. As the bootloader always runs first then you should be able to recover from a bad flash assuming it hasn't affected the bootloader itself. |
|||||||||
|
tman Comfort Distributors
|
If you're in the UK and the UCM was purchased from us (laser.com/cbus-shop.co.uk) then we'll be happy to reflash it with 7.056 and return it free of charge. You will need to ship it to us at your own cost. If you're in the UK but didn't purchase the UCM from us then there will be a £5 return shipping fee. You will need to ship it to us at your own cost. Return shipping would be via Royal Mail 1st class so untracked. If tracking is required then it would be an extra cost. For shipping costs for other countries or if you need the UCM reflashed, email support@laser.com with the country if applicable and UCM serial number. Last edited on Saturday Aug 30th, 2014 07:58 pm by tman |
|||||||||
|
ident Administrator
|
Thanks for the offer to upgrade the firmware for customers Your suggestion is good. The bootloader should be left in the flash during upgrade |
|||||||||