Thinking out loud, here are my thoughts on how I personally would go about debugging the situation.
First, I'm assuming from your use of the Win32::SerialPort module that you're on a Windows box. My first step would be to try using Hyperterminal or putty to manually test issuing the commands and to see what kind of responses that you get back from the device.
$PortObj->are_match("CorrRsp", ""); # correct response for CMD1
If I'm reading the documentation and your code correctly, you're telling the module that null ("") is a valid possible end string to determine the end of a response from the device. That might be correct, but it doesn't look right to me. In my mind, going with "\r" and/or "\r\n" makes more sense, but that may be completely wrong for your device.
$gotit = $PortObj->lookfor(100); #blocking read
Based on the documentation, you're read blocking until 100 characters are received. Unless you're 100% sure that you'll get at least 100 characters in response, this might create some problems. For debugging, you might want to try following the example "until" loop in the Win32::SerialPort documentation in the Methods_for_I/O_Processing section. Also, that particular example loop that I'm referring to has a $PortObj->lookclear; line to clear out the buffer. Your code is not calling this function. If you're going to reissue the command, it makes sense to me to clear out the read buffer to ensure that the next read call is reading the response to the latest issued command instead of previously issued commands.
Timeouts: Near the end of the Configuration and Capability Methods section of the Win32::SerialPort documentation, there's some notes about timeouts. Speaking from personal experience with using an older version of this module, I had to read this information several times to wrap my head around the timeouts in the module so that I could add in the proper delay (via sleep command) between sending a command and reading the response back. It might be worth it to take a few minutes to look at that stuff and your code to make sure that you're not trying to read before the device sends a response. Might not be a problem in your case, but it definitely was a problem for me when adding retries of commands in my code.
The Lookfor and I/O Processing section of the Win32::SerialPort documentation discusses the lastlook method, which can be used to "view" the "actual match and the characters after it (if any)". For debugging, it might be helpful to add a few lines inside your "until" loop to print out this information when the lookfor method doesn't find the proper success message from the device. That might help you figure out if you're reading too early or if you're hitting some edge case that you have not anticipated.
Well, those are my thoughts on what I personally would do to try to debug the problem. Hopefully one of these thoughts will either help you or at least trigger better ideas/suggestions that will help you solve the problem.
Good luck in your debugging efforts!
