Latest firmware update has created random exception errors
#1
Did a firmware update about two weeks ago, and since then I've been seeing random exception errors occurring. I'm unable to capture the screen as I'm only seeing it scroll through my modem buffer window on the BBS, but it has happened now about five times since the update - and was not happening at all before. The BBS is a 24x7 operation, so can definitely see where I was in a stable state before the update as to what has occurred over the last few weeks.

Anyone else been seeing this?
Mike
Reply
#2
I have not had any reports of issues, and I have not seen anything myself. What were you doing when exceptions were generated?

If you have not updated in awhile you might want to do AT&F to reset the settings to the defaults. Some new functions were added.

You can always go backwards to a previous version by using AT*DOWNGRADE.
Reply
#3
(01-09-2025, 10:21 PM)admin Wrote: I have not had any reports of issues, and I have not seen anything myself.  What were you doing when exceptions were generated?

If you have not updated in awhile you might want to do AT&F to reset the settings to the defaults.  Some new functions were added.

You can always go backwards to a previous version by using AT*DOWNGRADE.

This is occurring when the BBS is in an idle state waiting for a caller. As mentioned, I can't capture what the exception error is saying, it just scrolls by in the small screen area where I can see the modem communication screen.

Below is the snapshot of my modem settings:
RTS/CTS:disabled
DCD state: 1
DCD polarity: 1
CTS State:
CTS Polarity: 1
RTS State: 0
RTS Polarity: 1
Translation: None

b0 c0 e0 l0 m1 n0 q0 v1 w255 x1 s0:0 s1:0 s2:43 s3:13 s4:10 s5:8 s6:2 s7:60 s8:2 s9:6 s10:30  s11:90 s12:11 s25:0 s30:0 s37:6 s73:0 *b2400 *bl1024 *bt5 *c1 *ct1 *d1 *ho25 *l6502 *led5 *p1541 *r1 *t0 &c1 &d0 &g0 &k0 &q0 &s0
Reply
#4
Set W to 0. You have not done AT&F, so W is set to 255... that value should be either 0 or 1. So, in a terminal program type:

ATW0 <RETURN>
AT&W <RETURN>

This could be reason you are seeing the issue.
Reply
#5
(01-10-2025, 09:49 AM)admin Wrote: Set W to 0.  You have not done AT&F, so W is set to 255... that value should be either 0 or 1.    So, in a terminal program type:

ATW0 <RETURN>
AT&W <RETURN>

This could be reason you are seeing the issue.

Awesome, much thanks! and correct, I sent the settings before doing the AT&F so you could see my current config.
Thanks for the awesome and quick support!!
Reply
#6
I have made a new update (6.41) that checks the variable now to make sure that value for W is correct on power up when the EEPROM was not reset yet.
Reply
#7
I'm still getting random panics on the modem - only this time it is when a user is in a session with the BBS. No rhyme or reason that I can find, and I can't repeat an occurrence doing the same steps as other users if I call in remotely. unable to capture the text of the panic dump, but modem immediately resets and recovers.

W flag is at 0 now.
Running firmware version 6.41-01/20/25

flags:
b0 c0 e0 l0 m1 n0 q0 v1 w0 x1 s0:0 s1:0 s2:43 s3:13 s4:10 s5:8 s6:2 s7:60 s8:2 s9:6 s10:30 s11:900 s12:11 s25:0 s30:0 s37:6 s73:0 *b2400 *bl1024 *bt5 *c1 *ct1 *d1 *ho25 *l6502 *led5 *p1541 *r1 *t0 &c1 &d0 &g0 &k0 &q0 &s0

Also note: attempting AT*DOWNGRADE now results in an error:
process failed! - wrong http code
Reply
#8
You can now downgrade. I had the wrong spelling for the downgrade file.

Let me know if this resolves the issue. The difference between v6.30 and v6.4x was that I added the ability for the WiModem to recover from a router renew (where the channel or IP address changed). It could be that the router is changing and there is a bug in that handling code that is triggering this. Nobody has reported and issue, and I manually forced the router to change during testing, but there could be something that the router is sending that is not being handed.
Reply
#9
(02-06-2025, 03:07 PM)admin Wrote: You can now downgrade.  I had the wrong spelling for the downgrade file.

Let me know if this resolves the issue.  The difference between v6.30 and v6.4x was that I added the ability for the WiModem to recover from a router renew (where the channel or IP address changed).  It could be that the router is changing and there is a bug in that handling code that is triggering this.  Nobody has reported and issue, and I manually forced the router to change during testing, but there could be something that the router is sending that is not being handed.

I'm not sure what the issue actually is yet, but we narrowed it down to when a caller is calling in via an ipad using muffinterm.
There is some sort of incompatibility there.
Reply
#10
That's odd. You should not be able to send any type of data that causes an exception. Are you using Telnet or a RAW connection?
Reply




Users browsing this thread: 1 Guest(s)