Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

Please accept the use of cookies on our site

At PEmicro we use web browser cookies in order to provide you with an enhanced experience and in order to be able to do things like shopping cart processing and identify you when you login to our website.

Click here to accept

search inside this forum
search inside all forums
mpc5674f error 7
Stephen F. Feb 7, 2018 at 10:12 AM (10:12 hours)
Staff: Takao Y.

  • I have been programming a lot production units with a cyclone max for over a year without ever having an error 7. This is on an mpc5674f micro. After upgrading our equipment to cyclone universal fx's, and using the sap_convert_console to convert the image to work on universal, I now intermittently get error 7. All other hardware remained the same after the upgrade. The problem appears to only happen with units that have never been programmed before. We are not doing any kind of censoring. The cyclone max image had the shift frequency at option 5. I tried changing the shift frequency to option 15, but that appeared to make no difference. Our setup involves a ribbon cable going directly to the board, no external reset drivers.

    Is there anything else that I can look at, that I may be overlooking?


  • Greetings,

    Do you still have the cyclone max to confirm there are no problems with hardware like the ribbon cable, board, etc?

    Try using the PROG for PPCNEXUS software found within your cyclone software package and try programming step-by-step to see if you are able to program using software and replicate the error.

    Typically error $0007 is an issue with either communication speed, reset delay being too short, or hardware issues like ribbon cables.

    Takao Yamada

  • Thank you Takao,
    I am able to use the prog for ppcnexus software to program a unit step by step using the same shift frequency, but am unable to replicate the error. I haven't even been able to replicate the error in our lab. It seems like it only happens on boards that have never been programmed, and only intermittently. Our reset delay is set at 0 which has historically worked without issue on many other products with the same micro. The ribbon cables are a little on the long side, about double the length of the ones shipped with the the cyclone. However it is strange that the cyclone max worked without issue using these ribbon cables.

  • Greetings,

    Note that the cyclone max is much slower compared to the FX you have purchased. With faster frequencies, the higher the chance for EM interference to degrade the communication. Therefore I am not surprised that the max worked but the FX does not.

    Try shielding your ribbon cable. It could be as simple as wrapping tin foil around the cable and repeat the experiment.

    Takao Yamada

  • Thank you,
    I will try that and get back to you next week. Can you tell me what frequency is used on the ribbon cable for both programmers? Also could you tell me more information about what debug shift speed is? Is a "5" setting for a cyclone max, the same speed when used with a cyclone fx?

  • Greetings,

    A 5 in cyclone max is not the same as cyclone FX. If you read the frequency attached to option 5, you will find different numbers. It is like using a divider. If the clock is faster (like in the FX) then dividing by 5 is going to be different to a clock that is slower (like in the cyclone max).

    The shift frequency is the speed at which data is transferred from the cyclone to the chip. If the speed is fast, then you can program faster. But if there are things like delays or interference, then you will have errors.

    There is no correct frequency option to select. It is supposed to be trial-and-error and you will need to experiment what is the fastest yet reliable option to select as your shift frequency based on your chip, board, ribbon cable, how noisy (in EMI) of an environment you are in, etc.

    Takao Yamada

  • That makes sense. But I disagree on there being different numbers next to option 5. When I launch create image version 6.58 in a cyclone installation directory and select the mpc5674f algorithm I read 3.33Mhz next to option 5. When I launch create image version 3.49 in a cyclone max directory and select the algorithm, it also shows 3.33Mhz next option 5. So are you telling me that these numbers are wrong?

  • Also, over the course of many years, we have never been able to use option 0 for the shift frequency using the cyclone max, without causing large amounts of errors. What is the benefit of moving to a faster programmer (cyclone fx) if I am just going to have to slow it down to a speed that is slower than what the cyclone max was capable of running?

  • Another question I have is if the sap_convert_console will hold the same divider number ( like option 5) after it converts the image? Since an option 5 on a cyclone max is different than on a cyclone fx, won't this cause more error 7's after doing conversions?
    Sorry for the back to back to back posts, I just have a lot of questions.
    Have a great weekend!

  • Greetings,

    Try shortening the ribbon cable (or shield your cables with tin foil) and checking the schematic on TDI, TDO, and TCK lines to see what could prevent you from reaching faster speeds. Maybe it is missing pull-up resistors? Other benefits to using the FX is the security, touchscreen, internal memory space for more SAP images, cyclone control features, and in the future the use of cloud for controlling cyclones.

    After speaking with the cyclone engineers, we are technically both right when it comes to selecting option 5. In the GUI side, the customer will see the same frequency for option 5 no matter which cyclone or utility they are using. However, internally in the cyclone firmware we have to convert the frequency to a different option based on how fast the cyclone can operate. The reason why we kept the GUI side the same is because of the sap_convert_console. We did not want to manipulate the customer's image.

    We are removing this oddity in future utilities by having customers select the frequency itself and not the option level.

    Takao Yamada

  • Thank you for the great info!
    After looking at the schematic, there are no pull-ups on TDI, TDO or TCK. What should they be pulled up with? Would a 10k resistor work?

    Also could you tell me what top shift frequency of a cyclone fx is compared to a cyclone max?

  • Greetings,

    The recommended connection is 10K pull up on TDI, TDO, TCK, TMS, and RESET. Also make sure there are no current-limiting resistors on these signals. Once you have these pull-up resistors, that would ensure your rising edge are fast and reduce noise on the line. If slow rising-edges or noisy lines caused your slow speeds, then hopefully these pull-up resistors will help you reach faster speeds.

    Make sure the algorithm you are using is from year 2017. I generated pipe-lined algorithm to significantly boost the programming speed. My blog post about it here:

    Right now the highest frequency that customers can set on the cyclone FX rev A is 10 Mhz bus frequency (option 0)(10 Mhz bus frequency = MCU clk frequency 20Mhz). Our new rev B that is coming out soon can go to 100 Mhz and maybe even higher (100 Mhz bus frequency = MCU clk speed 200Mhz). I believe you can max out the MPC5674F at 264 Mhz if the PLL and external crystals are used to boost the bus clock. By default I think the MCU can self clk somewhere around 16 Mhz and hence why you might only be able to reach option 1 (7.1 Mhz bus = 14.2 Mhz clk).

    Takao Yamada

  • Hello Takao,
    We tried your suggestions, however we still not have been successful. Let me start by describing our set up. We have 6 nests each with their own programmer. We started by wrapping 4 of the ribbon cables in foil. Then we attached a ground wire to 2 of the ones that we wrapped. After none of those worked. We then attached 10k pull ups on tdi, tdo, tck, and tms. Reset has a pull up in the circuit. Which still did not improve first pass yield. We then swapped ribbon cables and saw no difference. We then swapped programmers from a nest that had the worst yield to a nest that had the best yield. After that swap it appears that the issues followed the programmer. The nest that had the best yield now has the worst, and the nest with the worst yield now has the best.

    We had 0 error 7's over the spread of several thousand units being programmed when the cyclone max's were installed. When we put the cyclone fx's in that is when they showed up. Even you said that the fastest that we can set the rev A fx is 10Mhz which is the same as the fastest on on the max. We tried using the same shift frequency option that we had on the max, and we tried using one that was 10 levels lower. This is an approx. 4-5% hit to our yield that is normally over 99%.

  • Greetings,

    The last thing to add is the 200ms reset delay. If that still does not help with the communication issue, then the next logical step is possibly sending us a board for evaluation so that our cyclone engineers can diagnose the issue. Is that a possibility?

    Takao Yamada

  • Hello,
    I know this is an old thread, but we are still having this issue.
    We tried the 200ms reset delay, and we tried shortening the ribbon cables to ~3inches

    Out of 6 nests there is one cyclone fx that has never had the error 7 issue. When we move the "good" cyclone fx to the one of the other nests it still will not fail in production.
    Sending P&E evaluation boards is possible, but I would like to make sure we ruled everything else out first. I am also not sure if it would do any good, as it sometimes takes 100's of units before the issue appears. It is generally about a 2% fail rate when averaged over a 5000 piece build. The failed units all pass on a retry.

    Could there be something wrong with these cyclones?

  • Greetings,

    Try lowering the debug shift speed even more. You want to select a speed that is fast yet always reliable. I think you are right on that fence where it is almost reliable.

    Takao Yamada

  • Hello,

    Tried going to option 31, and it still had same issue.

    Issue still seems to follow the cyclones

  • Greetings,

    With issues that are not easily reproducible, I also agree that sending the board is probably not going to help much.

    Would you check the firmware on all of these cyclones and confirm they are all the same?

    When you replace a cyclone FX with the "good" FX, are you also moving the power supply? Or are you only moving the cyclone itself? How about the power supply to the board?

    We are starting to think maybe power and voltage may be the problem. Since changing the speed it does not make a difference another thing to look at is power.

    Takao Yamada

  • They are all the same firmware and at 9.85. I do not move the power supply when I replace the fx, I only move the cyclone. The board power supply also remains the same. We also had the same power supplies when we used cyclone max's in the same setup. They are not the power supplies that p&e ships. They are much bigger hp6624a supplies. We never once had an error 7 when we had cyclone max's in these fixtures over the course of several thousand units. Also the software is the same. The only thing that has changes is the "upgrade" to the cyclone fx and the image conversion that was required.

  • Greetings,

    Try the latest firmware and software (firmware 9.90):

    We have included the ability to specify the debug shift speed or from a drop-down option. This allows you to select a specific frequency. Try using the same frequency on cyclone FX to when using cyclone max.

    Takao Yamada

  • Thank you Takao,
    I have downloaded the software, and installed the firmware on all 6 programmers, I will wait and see if there is any improvement. I was not aware of the new firmware.
    Is P&E having issues with cyclone universals? I noticed that the new ones that I got in the mail today are "rev b" instead of "rev a" like all of my other ones. What is the difference between these two revisions?

  • Greetings,

    No issues, but new features!
    Rev B has support for SWO, a protocol for ARM that allows for single-pin trace.

    Takao Yamada

  • How come you said below comment in an earlier post on this thread? I swear I am not trying to be difficult

    "Right now the highest frequency that customers can set on the cyclone FX rev A is 10 Mhz bus frequency (option 0)(10 Mhz bus frequency = MCU clk frequency 20Mhz). Our new rev B that is coming out soon can go to 100 Mhz and maybe even higher (100 Mhz bus frequency = MCU clk speed 200Mhz). I believe you can max out the MPC5674F at 264 Mhz if the PLL and external crystals are used to boost the bus clock. By default I think the MCU can self clk somewhere around 16 Mhz and hence why you might only be able to reach option 1 (7.1 Mhz bus = 14.2 Mhz clk)."

  • Greetings,

    The SWO is the main feature of rev B, but yes you can also increase the frequency to be able to program faster. This is mainly for the ARM devices, but it can affect PowerPC Nexus devices as well.

    Takao Yamada

  • The new firmware appears to have improved the issue. But it is definitely still an issue. I believe there to be some issue with cyclone universal fx's. I do not know if it is firmware or hardware, but there appears to be an issue.

Add comment

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

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