This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP-GANG430 Programming failure.

Other Parts Discussed in Thread: MSP430F2011, MSP-GANG

Hi,

This is about Programming MSP430F2011 using old MSP-GANG430.
Our customer's mass production line is still using MSP-GANG430 to program
MSP430F2011 and they will replace it to latest MSP-GANG as early as possible.

But currenly we have problem with the MSP-GANG430 programming unnecessary data
into INFO memory.This GANG430 was used to program more than 100K units of MSP430
but with recent programming we found more than 2000 MSP430s programmed with a
wrong data(i.e unnecessary data in INFO memory).The target program was programmed
into GANG430 last year and the target programming is done in standalone mode.
GUI version is v1.62.

We would like to know if there is any possibilty that GANG430's setting parameters
could change with continous usage for a long time?
Is there any possibilty that GANG430 misoperate and program the locked INFO A memory?

Best Regards
Kummi

  • Hi Kummi,

    Devices may ship from the factory with some data in the INFO memory segments from production - are you sure that might not be the case? INFO memory may not be blank - best practice is to have your programmer set to erase INFO memory (except INFOA of course, because you want to preserve the calibration data) if you plan to use INFO memory in your application.
    1. Can you describe in more detail the "extra data" in INFO memory? What is your expected INFO memory contents, versus what you actually see there? Are you just expecting it to be blank, or do you program some things there as part of your production programming.
    2. Can you show us the MSP-GANG430 programming setup in the GUI - I know that they use it in standalone mode but can you show us the settings they have configured in the GUI when they loaded up the MSP-GANG430? Without these settings it would be difficult to determine the issue.

    Regards,
    Katie
  • Hello Katie,

    Thank you very much for the quick response.

    Actually the INFO A calibration data is used for the clock settings
    so we are not writing to INFO A..Instead INFO D memory is used to store some data.
    This Gang430 is being used for more than 5 years.

    With this issue, the Gang430 writes a different data
    comapared to the actual. Below is a part of the binay..

    Actual Data 0x00001000: 30 40 BA FB 30 40 BE FB 34 40 18 02 38 94 0B 20
    Wrong Data 0x00001000: 20 40 BA 3B 00 00 AA  51 34 00 18 02 38 94 0B 20

    I have re-checked this Gang430 on my desk but there was no such issue
    except once, when I pressed START button while it is programming, the complete
    data was wrong/garbage (it also overwrote INFO A).This was only once and it was a different
    issue compared to the actual issue above.

    Meanwhile as this issue has occured only in the production line.
    We tried to re-produce the issue in the production line last week and
    we found 50 out of 50 programmed target had this issue.

    We tried to change the JTAG speed to slow through ini file "JtagSpeed=1"
    and re-wrote the Gang430 image and we found the problem didn't occur thereafter
    even if we returned the JTAG speed back to "JtagSpeed=0".
    Now we are not able to re-produce the issue anymore.

    I believe the issue is solved after re-writing the Gang430 image 
    so the problem could be the Gang430 storage memory or the Gang430 firmware.
    Is there any possibilty that Gang430 stored data/parameter change with the
    circumstances like voltage/noise/cable length etc..?

    Below is the GUI setting used.

    Best Regards
    kummi

  • Hi kummi,

    Do you have the original MSP-GANG430 image saved, in case a setting may have been different?

    Regards,
    Katie
  • Hi Katie,

    Unfortunately we don't have the original image as it was saved a year back.
    But the settings were as above.

    Regards
    Kummi
  • Hi Katie,

    As mentioned above currently we are not able to re-produce the issue.
    We will be using new MSP-GANG for the further mass production but we
    need to explain and understand the reason behind this issue.

    Actually this Gang430 was used to program more than 300K MSP430s till date
    and this issue occured recently.Around 2000 units of MSP430's had "00" written
    at some part of the INFO region.But 2000 units were normal.

    As mentioned above this issue disappeared when we re-written the Image file on the Gang430..

    Just for the explanation of this issue we would like to know what could be the cause.
    Is there any possibility that Gang430 stored data/parameter change with the
    circumstances like voltage/noise/cable length etc...?
    like Gang430's internal memory might have data flip under some circumstances?
    Can I assume the GUI version(v1.62) is a stable version.

    Regards
    Kummi

  • Hi Kummi,

    It is difficult to say what the root cause was without being able to reproduce the issue. I'm looking into whether the MSP-GANG430 internally uses any image CRC to check if the image is still good before programming - if it does have this feature, then it would be unlikely that you could have this problem without getting any error message and then it would be more likely that someone had re-loaded the MSP-GANG430 erroneously or something. The fact that the image was changed in the same way on all parts programmed suggests it wouldn't be some communication/line issue or else you'd expect it to be more sporadic. In addition, the devices must still be passing the verify step which indicates that whatever was programmed matches whatever the MSP-GANG430 expected to be programmed so this again would indicate it's probably not something happening in the communication lines. This again would make me think that someone may have loaded a different image accidentally, but I'll see what comes back about internal CRC for images.

    Regards,
    Katie
  • Hi Kummi,

    I've been informed that the src image CRC is verified. Have there been any more developments on your end? It does seem like different images were loaded erroneously.

  • Hi Katie, Cameron,

    Thank you for the continued tests.

    Here we were not able to re-produce the issue any more
    and the customer is continuing their mass production with the latest MSP-GANG.

    The root cause in our case is not clear but we shall close this issue here.

    Best Regards
    Kummi

**Attention** This is a public forum