Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
PROG32Z Erase Module Hang - What is the erase module process?
john S. Oct 17, 2014 at 03:29 PM (15:29 hours)
Staff: Johnny N.

  • I am running into problems with some production boards. We have about 30% of our boards failing when trying to erase the flash using the CABLE16/32 PE Micro product and PROG32Z. The symptoms are

    1. The connection process completes successfully
    2. The Erase Module (EM) command hangs
    - the character spins around and never stops
    - you must abort the process by pressing the <ESC> key

    We have tried the reset chip (RE) command before erasing the module but that did not help.

    We have looked for soldering problems on the CPU and Flash and have touched up all the solder joints. We have measured continutity on all the address, data and control lines to the chips. We could just replace the CPU and Flash but we did that on one board and it did not fix the problem.

    So I need to dig a little deeper into the alrorithm used by PROG32Z to erase the module. I'm hoping with that information I can devise a plan to probe some signals during the erase operation to see where the problem is located.

    I'm using the following

    - MC68332 processer
    - CABLE16/32 programmer
    - PROG32Z version 2.06.00.00
    - ~AM_400bw.32p programming algorithm file with base address set to 0
    - Flash is AM29F400B
    - RAM is AS7C4098-20TC




    Comments

  • Hi,

    Before we get into too much details about your setup, I have two simple questions.

    1) Was this setup working previously either on this computer or another one?

    2) What Windows OS are you running and did you read our FAQ on how to troubleshoot parallel port problems?
    http://www.pemicro.com/faqs/faq_view.cfm?id=4

    -Johnny

    • The configuration is running on a Windows PC running XP. The set up works fine on other boards. I can program many boards without errors. It is only a certain percentage of the boards (30%) that have this problem.

      So I'm sure it's not a programming hardware or software issue. This is some problem that is on the board I'm trying to program.

      • This is a problem with the assembled PCB. It is either a solder short, open connection or a failed component. I'm trying to assess which one without just shotgunning the problem are replacing the flash, RAM and processor because of the expense. I have about 12 of these board that act like this and I'm hoping you can provide some insight as to what to check in terms of signals or at least explain the process used by the Erase Module (EM) command.

        • John,

          I'm getting more information for you about erase module and how that works. Can you confirm that the flash is the exact same part on ALL the boards? Some flash devices (especially Intel-based Flash) prevent any writing/erasing until you run a "Clear All Locks" command.

          Regards,
          Johnny
          P&E

          • All Flash parts are the same.

  • I debugged this myself so I don't need help anymore. I did create a debugging procedure that I can send you. See below. The prog32z program uses a chip erase command to erase the entire flash.

    There does appear to be a bug in the handling of the signals after the chip erase command is sent to the chip. Prog32z does not detect the signals which are indicating the chip erase command was not accepted (stuck or contention on address/data lines causing DQ2 and DQ6 not to toggle) or the flash has failed (assertion of DQ5 after DQ2 and DQ6 stop toggling). Instead of reporting error conditions appropriately, prog32z just hangs and I'm not sure what it's waiting for.

    I developed a debugging procedure for these EM hangs in an excel file that I can share but I don't see anyway to upload files in the forum. It's a fairly simple procedure only requiring a dual channel o-scope. If you would like the debugging procedure then let me know how to send it to you. It might take a little editing because I used reference designators from my schematic.

    • Hi John,

      I'm running into a similar problem with a legacy board using MC68332 and AMD29F400 Flash, do you still have your debugging steps?

      • Eric B. issue was resolved with a new algorithm. There specific board configuration required some additional setup commands in the algorithm header.

  • Yes I do have the steps but there is no way to upload files here. I would need your e-mail address.

  • I put the excel spreadsheet in my drop box. It won't be there forever but I'll try to keep it there for a little while. Just look at the tab labeled "EM Command Debugging"

    We've found that most erase problems are caused by poor solder connections on either the processor or flash. At least that is the case on our boards. Typically re-soldering the flash with a hot air soldering station and using flux will do the trick. We slightly lift the part once the solder is melted and this typically reveals the unsoldered connections. Apply some flux and tap the top the part to seat it down and the pins will be soldered.

    https://www.dropbox.com/s/faqfoeur1wxg6uc/flashProgrammingErrors.xlsx?dl=0

    • I've grabbed the excel file from your dropbox, hopefully this will help, as we've already tried re-soldering the chips.

      Thanks for the quick reply!

  • Hope it helps

Add comment


   Want to comment? Please login or create a new PEMicro account.







© 2017 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement