1258 MKIIS locked up again

[K5WA]

SUCCESS!!! 
 
When the Ethernet cable was connected, the USB started working again.  That logic seems like it is backwards.  Shouldn't the USB connection be the connection that never fails?  Once I got the USB working again, I changed the IP on my computer so that I could connect directly to the RRC (default 192.168.0.227, my network is 192.168.1.1).  When I was connected, I changed to DHCP and connected the RRC to my network when I was able to adjust the other settings

To answer your questions:
1. I tried three different computers with the same result.  OS were Win7, Win2000 and WinXP
2. The RED light flashes after doing the 20 second reset.
3. Re: DNS errors; I got the DNS message when plugging/unplugging the USB cable per the log I sent you.  Maybe it was just coincidence?

Thanks for the suggestions.  I think I can now move forward again.

[Jan (Microbit)]

Very odd indeed! Here USB works just fine without Ethernet connected. Did you notice/check which IP settings the RRC had when you connected Ethernet? Is this the fact for all(both) of the failing units?

USB is very very complicated, so it requires for the firmware to have exact timings and normal execution in order to work. If, for ex, some other part of the firmware becomes busy it might happen that USB stops working.

[K5WA]

Both RRCs had the default IP because I had tried the 20 second reset to get things running again.  For what it is worth, here is a message that was in one of the RRCs:  "Data abort at 0x003b10c Called by 0x003bb34".  Neither one would respond via the USB port until I connected the Ethernet plug.  I honestly thought it would work without the Ethernet cable and never thought to try it until I got your previous message.  Now that I know how to bring it back to life, I can recover if it ever happens again.  The only thing I changed when this originally happened was to choose DHCP but that is probably a coincidence.

By the way, I loaded the new microRRC software and it works MUCH better than the older software.  The audio stays connected constantly now whereas I had to experiment with many, many settings to just get audio to stay on for 20-30 seconds before dropping out.  The CW interface still needs some work, I believe.  The first character seems to run into the second character and the spacing does not seem to be the same between all characters.  I'm sure this will get better over time and I will probably be using the RRC itself rather than the micro when I want to operate CW since I usually operate at 30+ wpm and the RRC works well for that purpose.  The micro CW would only be used in emergencies.

Thanks Jan!

[Jan (Microbit)]

The Data abort-message is interesting, but I need to know the FW version in order to make something of it.

I too think/thought that USB should work without Ethernet, especially when default settings have been applied. Do you mean that now when you have them up and running USB works without Ethernet connected?

As for the RRC micro it would be great if you could post its issues in its forums, mostly because it's another person(Roland) who mainly works with it.

[K5WA]

The Data abort message came from the RRC with 2.35 but not the one with 2.38.

Yes, USB works WITHOUT the Ethernet connection now.  The green LED still blinks until the Ethernet is connected but I can configure the RRC with the Setup Application via USB.  This is how I expected it to work originally.  Much better now.

OK, I'll post my experience with micro in that forum, but basically, the largest problem has been fixed with the new software.  The micro was unusable with the older software since the audio dropped out as the green bar constantly moved across the screen.

[Jan (Microbit)]

So while things are fresh in memory, is this what happened?

1/
You used Setup Manager to change from static IP to DHCP? Did you just check the DHCP box and then hit Save? Were Ethernet connected or not during that? Did you do it to more than one unit?

2/
You found the unit(s) in a state which not allowed further USB access?

3/
You tried short and long reset, but none worked?

4/
You connected a terminal and made some start-up output dumps?

5/
You connected Ethernet and suddenly USB started to work?

Any other detail you remember? I know I ask a lot, hehe, but I really would like to know what causes this very strange behaviour so that it might be possible to avoid it in the future, hopefully by some software modification.

[Jan (Microbit)]

The Data abort message came from the RRC with 2.35 but not the one with 2.38.

Looking into this I see that the data abort occurred somewhere in the TCP/IP stack=not in our firmware code as such. The conclusion I make from that and your problem with USB not working until you connected Ethernet is that somehow something got invalid/wrong with the network part of the firmware, making the firmware not executing normally and so the time critical USB code too suffered from this. Would surely have been valuable to either now what happened to the setup or being able to reproduce the error. 

[K5WA]

You have the facts correct in 1-5. 

I believe the Ethernet was not connected when I changed to DHCP because I was moving these units to the remote site for testing at the time.  The remote site has 192.168.0.1 as the main router address while my home network uses 192.168.1.1.  The Control RRC will also be moving to another network where I don't know the setup so I wanted to set the control RRC to DHCP to allow it to adapt to whatever network it is used in.  This seems to be the main cause of the lock up.  When in the locked up state, USB access was not possible.  I was only able to make progress after you mentioned I could get some status via the COM1 message.  That allowed me to see what IP setting the control RRC was actually stuck upon.  The I configured a PC to a static IP that was compatible with the IP inside the RRC.  This allowed me to access the RRC via Ethernet so I could configure it again because the USB port was not working.  One other thing that is probably insignificant is that I use Dynamic DNS.

It seems to me that there should be no possibility of the USB port becoming unusable.  I got the same result on three different computers and operating systems (Win2000, WinXP and Win7) a so I don't think it could be USB port issue on my end.

I hope that helps in future firmware development.

[K5WA]

Jan, one last thing.  On my Win7 machine, I have Setup Version 1.9 loaded however, I don't see that version on your download page.  My other two machine only have 1.8 loaded.  I am not sure where I got 1.9 but could that be part of the problem?  Was 1.9 a beta version that was posted for a short time and then removed?

[Jan (Microbit)]

You have the facts correct in 1-5. 

I believe the Ethernet was not connected when I changed to DHCP because I was moving these units to the remote site for testing at the time.  The remote site has 192.168.0.1 as the main router address while my home network uses 192.168.1.1.  The Control RRC will also be moving to another network where I don't know the setup so I wanted to set the control RRC to DHCP to allow it to adapt to whatever network it is used in.  This seems to be the main cause of the lock up.  When in the locked up state, USB access was not possible.  I was only able to make progress after you mentioned I could get some status via the COM1 message.  That allowed me to see what IP setting the control RRC was actually stuck upon.  The I configured a PC to a static IP that was compatible with the IP inside the RRC.  This allowed me to access the RRC via Ethernet so I could configure it again because the USB port was not working.  One other thing that is probably insignificant is that I use Dynamic DNS.

Hmm... But at which point in all this did the USB start working again? I thought it was when you connected Ethernet, but now I am not sure it was that "early".

It seems to me that there should be no possibility of the USB port becoming unusable.  I got the same result on three different computers and operating systems (Win2000, WinXP and Win7) a so I don't think it could be USB port issue on my end.

I hope that helps in future firmware development.

USB is, as I wrote in a earlier post, very complicated. As such it needs all of the firmware running to work normally. Ideally it would always work, but in practice software will sometimes run into situations which cause problems like this. One can only take as much action as possible in order to prevent it from happening, but 100% fail safe is not possible, no matter how much one would wish it to be true 

[Jan (Microbit)]

Jan, one last thing.  On my Win7 machine, I have Setup Version 1.9 loaded however, I don't see that version on your download page.  My other two machine only have 1.8 loaded.  I am not sure where I got 1.9 but could that be part of the problem?  Was 1.9 a beta version that was posted for a short time and then removed?

1.9 is available now for D/L. There should not have been a beta available before. A couple of persons might have got a 1.9-beta by email though.