microHD Repeatedly Rebooting After .udf Upload

[primestar31]

I'm getting a "fail to get version" message,
after test serial port status - finished,
at Collect STB information.

tried several times with .udf, and .abs files..
what next?

BTW, got the cable, and it seems to work

Can you provide more info? What version Windows, which TTL board you are using (oh yeah, you said you were using the dual 3.3 and 5v one) etc, what you tried, at what step the error message comes up, everything you can think of. Check your jumper connections for continuity between usb board and MicroHD board

 

[KE4EST]

I'm sure Babadem will get his(if he don't fall asleep at the receiver)

 

[northgeorgia]

I'm getting a "fail to get version" message,
after test serial port status - finished,
at Collect STB information.

tried several times with .udf, and .abs files..
what next?

BTW, got the cable, and it seems to work

Two things I can think of....download and run the driver installation from http://prolificusa.com/pl-2303hx-drivers/

I also had a weird error message like that (I don't remember if it said "fail to get version" or "fail to read serial", etc.)....and that was very frustrating because the deal was that the pins all had to be connected into place just so. Try fiddling with them (with the STB disconnected from the power supply and the USB from the computer, of course!) and retry. At one point it took me a good 5 - 10 mins until I finally had a connection.

 

[Babadem]

Success! I loaded another user's UDF file and now the machine is operating normally. Brian, I used the ALI editor that was provided for the microHD but for some reason, that lzma.exe file wasn't included. What I did was just -try- to copy that .exe file from my openbox's ali editor into the folder with the microHD's editor to see what would happen, and it worked. I don't know if the lzma.exe was originally included and it somehow was deleted, or maybe wasn't considered necessary, but the microHD's ALI editor kept flashing an error message without it. Do you know if there is supposed to be an lzma.exe file with the microHD version of ALI editor?

Anyway, thanks for all the help. I used the 5 pin dual version 5V/3.3V with and it works fine, but the wire attachments have to be slid on just so, or it doesn't register the serial connection.

Congratulations! I will be looking into this.

 

[Babadem]

I'm getting a "fail to get version" message,
after test serial port status - finished,
at Collect STB information.

tried several times with .udf, and .abs files..
what next?

BTW, got the cable, and it seems to work

Make sure the plugs are seated properly on the 4 pins on the MicroHD. Did you choose your com port number as indicated in file manager of you PC?

 

[Babadem]

I'm sure Babadem will get his(if he don't fall asleep at the receiver)

................isn't it amazing how you lose track of time when your fiddling with a hubby that:

1. keeps you at home.
2. drains your pocket money.
3. endlessly looking for more FTA channels, but quickly abandon them to search for the next 5 minute satellite feed.
4. Run out in the freezing rain and cold to adjust an lnb/dish for a better signal knowing fully well that the dish is undersized to receive the signal, but you want to prove that you could do it.
5. Hardly watch the channels, but quick to showoff to your friends/family the types of feeds you can get.

 

[SatelliteAV]

maybe could a firmware be programmed to do some sort of check on a .udf file, and reject installing it if it doesn't pass muster?

Would need to be able to duplicate the issue in order to resolve

The .udf file has so many variables throughout possible thousands of combinations of settings that it cannot be checked like firmware. The total size is calculated, but that does not address errors occurring within the database envelope and null settings.

 

[primestar31]

Anyway to do some sort of MD5 checksum of the .udf file? Perhaps it's some sort of interaction with that specific last firmware download, AND the .udf file.

It makes NO sense that some people actually loaded the firmware, and watched tv for some hours before the MicroHD just decided to start the reboot bit. That is, if we are getting the whole story. Now, say if they were watching tv for some hours, then decided to go in and scan a transponder, or change some settings, and THEN the reboots started?.....

Would it be possible for one of the people with the constant reboots to pull their corrupted .udf file out of the MicroHD, before flashing a "good" one back to the receiver? Also, we should have somebody JUST reflash a good .udf file without flashing a .abs file first. Nice to have all sorts of datapoints when speculating things!...

 

[northgeorgia]

Unfortunately, I didn't keep the .udf file from the rebooting, although it was a version that came with the Galaxy19 downloaded firmware. I did try to load my own .udf into the system, but when I saw it didn't load correctly, I reverted to the downloaded version. I can say that I was doing a multiple blind scan with no problems, and it had just finished scanning the last satellite in the list when it went into the cycle. So in my case, I wasn't watching TV at that moment (although I had earlier in the morning), but had rather just completed a blind scan. I don't remember if I hit exit and it started, or it froze up, and I replugged the STB and it started. I know in my case, I did try reflashing with the .abs first (not the .udf) and I had no success, but the other unknown variable was that mysterious lzma.exe file. I put a copy of it into the same folder as the microHD ALI editor before loading a new .udf file.

 

[primestar31]

Unfortunately, I didn't keep the .udf file from the rebooting, although it was a version that came with the Galaxy19 downloaded firmware. I did try to load my own .udf into the system, but when I saw it didn't load correctly, I reverted to the downloaded version. I can say that I was doing a multiple blind scan with no problems, and it had just finished scanning the last satellite in the list when it went into the cycle. So in my case, I wasn't watching TV at that moment (although I had earlier in the morning), but had rather just completed a blind scan. I don't remember if I hit exit and it started, or it froze up, and I replugged the STB and it started. I know in my case, I did try reflashing with the .abs first (not the .udf) and I had no success, but the other unknown variable was that mysterious lzma.exe file. I put a copy of it into the same folder as the microHD ALI editor before loading a new .udf file.

The present firmwares don't replace the .udf file, but doing a factory reset after loading it does "zero" out the one we have loaded. So, if a corrupt .udf is what's causing people's constant reboots, then reflashing the present versions of .abs files won't fix anything. We need somebody to first try pulling out a copy of their corrupt .udf file (if that's possible, I don't know?), saving it with a different name, and then reflashing a good one back to the receiver. If that fixes the reboots, then they can PM Brian with the "corrupt" .udf file, and maybe he can figure it out. Also, do you remember WHICH satellite was the last one you scanned before it started the boot loop? That might help track this down.

 

[northgeorgia]

Yep, it was 127 W (Ku).

 

[wallyhts]

I found the right cable for the header but I want to besure 100% before posting the connecter name.

 

[primestar31]

I found the right cable for the header but I want to be sure 100% before posting the connecter name.

Looks good to me, provided they actually electrically contact the pins on the MicroHD, and the wires from the usb device go to the proper connections per Brian's posted instructions in his flashing guide. Color of wire is not important, as long as they connect to what they should.

In Brian's guide for instance, it shows the colors from Left to Right in your picture as:
1: White (TX) 2: Green (RX) 3: Red (+5v) 4: Black (Ground)

It is possible to use a T pin, to push the little connector piece on each individual connector, and pop them out and re-arrange them to a different slot. That would help get it slightly closer to matching some of the colors of the wires in Brian's guide. But like I said, wire color isn't important.

 

[wallyhts]

Looks good to me, provided they actually electrically contact the pins on the MicroHD, and the wires from the usb device go to the proper connections per Brian's posted instructions in his flashing guide.

For sure I'm making a video and more pics details etc.

 

[KE4EST]

Try to not make your 5 min video, 127MB like last time.

 

[northgeorgia]

For sure I'm making a video and more pics details etc.

If it works, that would be a major frustration saver! I almost never got the pins to line up just right, no matter how many times I did it. I think I have an easier time pulling in Tijuana on Satmex 5 on my 90 cm dish

 

[rgk]

"It makes NO sense that some people actually loaded the firmware, and watched tv for some hours before the MicroHD just decided to start the reboot bit."...

If the firmware isn't allocating enough memory for data the system could operate normally for a time. Once the data starts getting stored in memory locations allocated for the firm\software all kinds of nasty things can start to happen.

 

[SatelliteAV]

If the firmware isn't allocating enough memory for data the system could operate normally for a time. Once the data starts getting stored in memory locations allocated for the firm\software all kinds of nasty things can start to happen.

Definately not the case.....

More likely that the .udf file was corrupt and some data was stored in an incorrect memory block. Since a satellite scan was just completed when the power cycle loop began, this memory location was obviously compromised.

Just posted the procedure for User Data Base (.udf) file update via USB / TTL serial connection.
http://www.satelliteguys.us/threads...via-Internal-TTL-Header?p=2963448#post2963448

 

[rgk]

Don't get me wrong, I think the Micro is a great little machine, but it's not perfect yet. The firm\software ideally wouldn't permit a corrupted config. or data file to affect the O.S.. It's just something that sometimes happens with new software, especially in an embedded environment where memory is limited or different methods are used by the programmer to improve performance.

 

[wallyhts]

V 0.01

It works!