Bricked power clipper

[maxvoxel8]

I obtained a power clipper and used it for a few hours. It originally came with firmware version 2.1.0.39 and I updated it through each version as the "Important Readme.txt" said. I had it running on 2.3.2.5 and then tried to update to 2.4.0.180. After this it did not restart anymore. The orange LED no longer comes on and I can't connect over Ethernet or use any of the USB drive bootup features. I tried reflashing it using the instructions here from an image taken off a known good clipper, (http://forums.deltatau.com/showthread.php?tid=169&highlight=Winimage) and it still does nothing. Does anyone have any advice?

[steve.milici]

Something may have inadvertently "interrupted" the update process and possibly corrupted the Kernel.

 

Please contact the TS Group at support@deltatau.com for further troubleshooting. Providing the serial port boot response could be very useful.

[dougjr17]

I obtained a power clipper and used it for a few hours. It originally came with firmware version 2.1.0.39 and I updated it through each version as the "Important Readme.txt" said. I had it running on 2.3.2.5 and then tried to update to 2.4.0.180. After this it did not restart anymore. The orange LED no longer comes on and I can't connect over Ethernet or use any of the USB drive bootup features. I tried reflashing it using the instructions here from an image taken off a known good clipper, (http://forums.deltatau.com/showthread.php?tid=169&highlight=Winimage) and it still does nothing. Does anyone have any advice?

 

 

 

Very interesting - I experienced the exact same issue last year where 2.1.0.39 was the last firmware version I could update the power clipper that originally came with version 1.6.x firmware. After days of building DB9 to special pinout header for serial console connection onto the power clipper, finding the right DHCP/BOOTP utility to offer a lease and boot from TFTP image, then carefully typing in the commands to unprotect the bootloader memory regions that need re-flashing, copying the payload and re-locking down those memory regions, upon reboot it would work and you could use the “firmware in USB media storage under a specially named folder” method to then complete reversing the firmware back to 2.1.0.39.

 

 

Once you plug that serial console port in and watch the output via putty/terminal connection to it, I suspect you will see that the boot sequence stops right after it enumerates this NOR flash storage where kernel and bootloader reside. For me the boot process halted there in mid sentence and a few minutes later I suspect a watchdog timer would expire and restart the whole cycle. I have a whole folder with all the logs, command sequence and utilities I used to keep reverting back to 2.1.0.39 or earlier. You cannot access to the NOR flash where kernel and bootloader live from the USB connector where you can mount the rest of the PPMAC’s storage when the board if off and you attach that micro-usb connector to a PC. Instead, you need to load the bootloader from TFTP over the network, unprotect/erase the NOR flash storage area for the bootloader and then copy the data obtained via TFTP over Ethernet port. This also obviously requires configuring proper IP address/Ethernet interface settings that will allow you to reach the TFTP host holding the proper bootloader code.

 

Also don’t forget immediately when the board powers on you need to hit space or some other key via putty/serial terminal, like pressing DEL to get into a PC BIOS when it powers up, in order to interrupt the default boot cycle and instead give the board an IP address/subnet mask on same subnet as TFTP/BOOTP hosting machine with bootloader image file resides.

 

Let me know if you still need this and I will dig up that archive - it would take me two days to get it to you.

[maxvoxel8]

Thanks, but I already sent the clipper back and got another one which has not developed this problem.