Hi,
I'm hoping someone can help, but there is quite a story so please bear with me.
I have a board that I can use mfgtool (v1.6.2.032) that uce_ivt.sb and eboot_ivt.sb go in fine, but I get errors on NK.nb0.
5 - Panel A Start <CMD/> type="push" body="fwtype:NK_NB" file="" timeout="10" onError="" text="Specify firmware type.".
5 - Panel A Finished <CMD/> type="push" body="fwtype:NK_NB" file="" timeout="10" onError="" text="Specify firmware type." SUCCESS code=0.
5 - Panel A Start <CMD/> type="push" body="send" file="files/nk.nb0" timeout="10" onError="" text="Sending a firmware file.".
5 - Panel A Finished <CMD/> type="push" body="send" file="files/nk.nb0" timeout="10" onError="" text="Sending a firmware file." FAIL code=-1.
Panel A: Updater Error 0xffffffff (-1) -
I've looked at the mfgtool SRC for v1.6.2.055 and I can see that the return value of -1 is set by retValue = m_pUTP->UtpWrite(csCmdBody, fullFileName, callback); in OpUtpUpdate.cpp, however I don't understand why.
UtpWrite will either return ERROR_OPEN_FAILED (110L), ERROR_INVALID_HANDLE (6L) or whatever gets set in cmdProgress.error (((DoneState*)transaction.GetCurrentState())->GetResponseInfo()).
GetResponseInfo returns m_ResponseInfo which I can only see as being set inside the constructor of DoneState. The only references to DoneState include the values -65535 (Polling stalled), -65536 (Illegal response code), or (m_pCurrentState->GetUtpMsg()->GetResponseInfo()).
My understanding could be completely wrong, but I should be able to view the UTP messages using capture software (like Wireshark and USBpcap) so somewhere there should be a -1 in GetResponseInfo(). GetResponseInfo() just takes the 4 bytes of ScsiSenseData.Information, flips the order and puts it in UInt32.
I've run Wireshark and USBpcap but I am struggling to tie everything together. I can see the host sending the push commands (MediaType:NAND, QueryStoreNameLNAND FLASH Storage,Timeout:10, wfw, fwtype:EB_SB, send). This is followed by 10 packets 65563 bytes long, something weird, 1 packet 2507 bytes long, and then the save command. The something weird is that a normal transfer is as follows:
Host->Device SCSI Command: 0xf0 LUN:0x00
Host->Device SCSI: Data Out LUN: 0x00 (0xf0 Request Data)
Device->Host SCSI: Response LUN: 0x00 (CDB:0xf0) (Good)
But the weird bit was that after 10 packets instead of sending SCSI Command: 0xf0 LUN:0x00 we see the following:
Host->Device SCSI: Test Unit Read LUN: 0x00
Device->Host SCSI: Response LUN: 0x00 (Test Unit Ready) (Check Condition)
Host->Device SCSI: Request Sense LUN: 0x00
Device->Host SCSI: Data In LUN: 0x00 (Request Sense Response Data)
Device->Host SCSI: Response LUN: 0x00 (Request Sense) (Good)
Obviously after the weird bit we send another packet, so I don't know what caused that to happen, or it is just part of normal SCSI operation.
Finally we send the following push commands (save, wfw, fw_type:NK_NB, send)
We successfully send 28 packets 65535 bytes long before doing the Request Sense stuff, but then everything must be good as we carry on and send another 12 packets.
We then do the Request Sense Stuff again with the same response information but it just resends over and over again. I cannot see why this would cause anything to fail, but it clearly does.
At this point mfgtool stops and returns error -1. This happens over half of the time, and always fails at the same point.
Sorry for the long post but I need an answer on this. I've tried building mfgtool 1.6.2.055 from source but it wouldn't build for me.
Regards,
Stephen
What OS are you running the Manufacturing tool in? We found issue when running it in Win 8.1, but works great in Win 7. Not sure if that is the issue, I would have to look into it more. Clarifying this is great and if helps you resolve this issue ... then even better! Good luck!
Tom,
Would it be helpful if I sent you the Wireshark capture as I'd like to know why this is not working?
Regards,
Stephen
Hi Stephen,
I am by no means a software expert, so I doubt I will be any help. As I stated above, we just ran our tool in Win 7 with admin privileges and it works. I suggest you try to run the tool on another PC. Not saying that will fix it, but sometimes it is easier to do that and confirm the original error you have been receiving.
Wish I could be more help!
Best regards,
Tom Wood
I am using Windows7 and USB 2.0.
I know that there are issues with Windows8 and USB3, so I've avoided that.