UC540 hangs during speed dial to button programming

[hopkintondrug]

Hello,

I have been experiencing a strange issue.  When programming a button on the 500s sidecar using "button 3:81XXXXXXXXXX" from the CLI, my UC540 crashed.  with 8 to find an outside line + 1 and the number.  This was verified twice.  The third time it crashed the button was actually on a 504g and not a sidecar, and the box never came back up. The NVRAM went bad on the last crash.  Luckily i had another UC handy and the system is functional again but i'm not going to test this issue again due to the result of the last attempt.

So my question:  Has anyone experienced this issue?  If not, do you think the NVRAM dying could have caused the flaw until, finally, it gave out?  Any help is much appreciated.

Fletcher

[David Trad]

Hi Fletcher,

It sounds like a memory issue, have seen this on the UC520 but that was a long time ago maybe 2 years ago.

First thing first you should log a case on this so you can look at the potential of RMAing the appliance, but also let them try and capture some data so it can be used for future referrence.

Secondly if you want to go through the excercise (But I do not encourage it) you can whipe the NVRAM on the command line, then use the factory default CFG file after the reboot. If for some reason there is corruption it might clean this out, but I do suspect that the problem will resolve itself but only for a short period of time untill it hit a bad sector and begun crashing again (Think of a BSOD )

Either way let us know how you go and what the outcome is

Cheers,

David.

[Darren DeCroock]

The way in which you are programming the speeddial is incorrect..  When you try to add the statement "button 3:81xxxxxxxx" the ephone is looking for ephone-dn 81xxxxxxxx.

You can add a speeddial in CCA under the "users and phones" section by clicking on the speed dial tab when editing the phone.  Or though CLI try adding this command to the ephone:  speed-dial 1 81xxxxxxxx label "test"

Thank you,

Darren

[hopkintondrug]

Thanks both for the replies.

David, I had been meaning to pull the logs off of the flash. But from looking at them previously, my flawed command was the final one issued before each crash:

CMD: 'button 13:818662389791' 09:21:31 EST Thu Feb 10 2011 

09:21:31 EST Thu Feb 10 2011: Unexpected exception to CPU: vector 200,

PC = 0x80720348, LR = 0x8071FFF8 <-immediate crash afterwards

It was most definately a trigger.

Darren, thanks for the heads up, i don't know how i started using that syntax since i knew that in "button 3:10", 10 is the ephone-dn.. ah well.

Anyone have a UC540 they want to test the suspect command on?  Maybe it wasn't the RAM.

Fletcher

[Darren DeCroock]

I tested this command on my UC560, just to see what would happen... 

When I did this, it looked like it took the command, but then my UC560 rebooted.  It did come back up, and did not save the change to the config, so everything does seem to be woring normally.   But it definitely did not like that command..

Thank you,

Darren

[hopkintondrug]

Darren,

That's great information!  Thanks for being experimental, now that i know it was definately my oddball command, i won't be so on edge every time i change a button function.

Fletcher