MfgTool Newer fully tested release

[AbisaiNegrete]

Hello,

In neary 1 of 10 cases the MfgTool with the version 1.6.2.048 or 1.6.2.050 terminates with a windows dialog that the program is no longer working. After a restart of the MfgTool the process can be completed.This problem cannot be reproduced with the version 1.6.2.042.

Could you tell me when will be ready a newer fully tested release of this tool?Which version will it be?

[lategoodbye]

@Chris

I noticed that the crash (in about 4 tries) always occurred in the second run at my notebook. The first run succed and then the second leads to a crash. I attached a screenshot (including a stacktrace) and a debug output. I hope it helps.

[lategoodbye]

Ugh! This smells like a race condition.

@Andre

Thanks for your patches, but they didn't helped very much. Now the crash occured at a different position.

[andrew_questps]

I know I made a couple of changes in one of the libraries to fix this issue. My MFG tool only crashes rarely now, I think usually after I've left it running all night.

I made the switch statement in OpUtpUpdate.cpp

                 case OPEVENT_VOLUME_ARRIVAL:
                    if ( m_CurrentDeviceState == UCL::DeviceState::Updater )
                    {
                        if (m_pUTP != NULL)
                        {
                            delete m_pUTP;
                            m_pUTP = NULL;
                        }
                        Sleep(2000);
                        m_pUTP = new UpdateTransportProtocol((Volume*)m_pUSBPort->_device);
                    }
                    break;
                case OPEVENT_VOLUME_REMOVAL:
                    if (m_pUTP != NULL)
                    {
                        delete m_pUTP;
                        m_pUTP = NULL;
                        Sleep(2000);

and in UpdateTransportProtocol.h I added a private member

DWORD dwUtpDeviceAddr;

then edited UpdateTransportProtocol(Volume* pDevice)

to have:
    {
        m_pUtpDevice = pDevice;
        dwUtpDeviceAddr = (DWORD)m_pUtpDevice;
        m_MaxPacketSize = Volume::MaxTransferSizeInBytes;

UtpCommand(CString cmd) to have:

        if ((UINT32)(m_pUtpDevice->m_pBuffer) & 0xF0000000)
            return FALSE;
        if(m_pUtpDevice != NULL)
            ((Volume*)m_pUtpDevice)->Notify(cmdProgress);

and finally UtpWrite(...) to have

dwUtpDeviceAddr = (DWORD)m_pUtpDevice;

instead of DWORD dwUtpDeviceAddr = (DWORD)m_pUtpDevice;

Not sure if that I had the exact same issue but I can recall there being a null-reference that was crashing the app.

Offtopic:

Also any idea how I can get the source for the 1.6.2.055 for the binary that is available in this group?

[lategoodbye]

I started Visual Studio 2008 and debugged the MfgTool. When the crash occured i get the following dialog message (mfgtool_crash1.png).

Unhandled exception at 0x006a62a2 in MfgTool.ext: 0xC0000005:

Segmentation fault at reading on position 0xfeeefef2.

The problem occured in the module device.cpp. For more information look at the second screenshot (mfgtool_crash2.png). It looks like a null pointer exception.

[lategoodbye]

Here is the ucl.xml for the MfgTool.

[lategoodbye]

Hello,

i reported this problem as a service request at freescale. This problem appeared in combination with the i.MX28. The Host PC is a Windows 7 Pro SP1 64 bit (only USB2.0).

Steps to reproduce the problem:

1. Start MfgTool - Version 1.6.2.048 or 1.6.2.050
2. Connect the Target board via USB to the hub
3. Select Options - Configuration - USB Port
4. Check the HID-Device in the tree view
5. Press button OK in the dialog
6. Select the profile
   
7. Press the green button Start

At the step "Booting update firmware", windows opens the dialog i.MX Manufacturing tool no longer works and only termination of the program is possible (look at mfgtool.jpg).

An extract of the MfgTool event log in good case (no termination) is attached as mfgtool_goog.log. An extract of the MfgTool event log in bad case (termination) is attached as mfgtool_bad.log.

Also an import note to error vs pass, this is not a pattern 1 to 10, it's more randomly.

Because the firmware is for a customer, i'm unable to upload this in a public board. But i could upload the ucl.xml.

I'm only a software developer, please tell how or where can i see that the device disconnect from the USB bus?

[ChrisWilliamson]

A program crash is typically fairly easy to diagnose and fix. I am sure that this problem has not been seen by the development team. It's interesting that the problem isn't seen in 1.6.2.042, that should be helpful in tracking down the issue. If there is any other info you can provide that might be relevant it would be helpful. Anything that distiguishes the 1 out of 10 error vs pass? Do you hear the device disconnect from the USB bus in the failing case? To me this makes the most sense. The app is trying to write to the device and the device goes away (probably due to a firmware error) and the host deletes the device object while another thread is trying to write to the device. If this is true, fixing the application crash would not fix the error that is causing the device to disconnect from the USB bus. That would be on the firmware side to debug. All conjecture of course, but anything you could do to help identify the symptoms would be helpful. Or narrow down the failing mechanism. We might need to get the binary being loaded to the device to reproduce the error.

Best regards,

Chris