Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
Avoiding manual POR using CPROGCFV1
Ian R. Sep 17, 2015 at 09:24 AM (09:24 hours)
Staff: Takao Y.

  • Hello,

    I have been using CPROGCFV1 successfully to program Coldfire V1 (MCF51AC256) processors using the Multilink Universal via the command line. However, I am trying to increase the level of automation, and the occasional need to perform a manual power-on-reset to enter debug mode is causing some issues.

    I find that the need to do the manual POR only ever happens the first time a MCU is being programmed (ie. fresh board). But not all fresh boards require it. When the pop-up shows, a quick power cycle and pressing OK does the trick and it happily programs. However, in the new highly automated setup, the pop-up stops the test sequence and there may not be an operator there to address this. The new setup also makes it tricky for an operator to perform a power cycle.

    I see in the user guide that there are some command line options that could conceivably assist in needing the manual POR. The reset_delay and freq options seem promising. Might using these options help me out?

    If there is something else recommended, please let me know. Note that the MCU is being externally powered and controlled, but since the pop-up only comes up on some boards, it is hard to implement a workaround. Since I'm using the Multilink Universal, I don't have the option to provide power via the debugger.

    Let me know what you think, thanks!

    Ian




    Comments

  • Greetings,

    Reset delay will add a delay after the P&E hardware toggles the reset line. This helps when your board has a reset circuitry that may take time to stabilize. This will not help you at all in POR.

    Frequency Option is to help develop a better stable communication between the P&E hardware and the chip/board. This will also not help you at all in POR.

    You using the wrong hardware to try automation. Multilinks are best for development and prototyping stages. Not for production. This is why we sell the cyclone hardware that can do standalone programming and can control power. When using the cyclone you will never see the warning, you do not even need a computer, and you can control it remotely. That is how production programmers work:
    http://www.pemicro.com/products/product_viewDetails.cfm?product_id=1

    There is not much you can do with the multilink to get around POR. The multilink does not control the power of your chip. POR is necessary for first time/fresh chips because the chip gets external power and immediately tries to execute code. There is no code in flash so it is perpetually in RESET. A manual POR is necessary while the P&E hardware controls the RESET line.


    Takao Yamada

    • Hello Takao,

      Thanks for the quick reply. I happen to have a Cyclone Pro, so I just tried it and I'm seeing the same issue. With the Cyclone Pro I have the option of powering the target, but our hardware setup doesn't really allow me to power the board externally as it's powered via a card edge to a test fixture.

      If I can find a way to get around this with the Cyclone, that would be great. Do you have any other suggestions? If I can find a way to synchronize the external power control with the Cyclone, I think I could avoid the pop-up. I have taken a very quick look at the Cyclone Automated Control Package manual, but I do wonder if I'll end up in the same scenario if the Cyclone isn't controlling the power.

      Let me know what you think, thanks for the help!

      Ian

  • Greetings,

    You have to give the power control to the cyclone. The cyclone must hold RESET line low while you or the cyclone power cycles the chip. This is the only way to get out of the perpetual reset I mentioned earlier.

    You do not need external power to program the board. Let the cyclone provide power to the chip alone to program it. Then after programming the chip you can remove the cyclone and power the board up externally. Otherwise, you are forever stuck having to manually power up the chip and there is nothing you can do about it.


    Takao Yamada

    • Takao,

      Thanks again. Looks like I can set the Cyclone Pro to use its internal power to apply on pin 6 of the BDM header quite easily using jumper settings, so I will try this. If that works well, it will be easy for me to do as you suggest for chip and board powering. I will let you know how that goes. Thanks!

      Ian

    • Takao,

      I was eventually able to program the flash on the board using the Cyclone Pro and having it control power via BDM pin 6. One issue though: the first time that it ran, it got stuck on the Erase Module step. I had to abort. The next time it ran, it erased and programmed the flash fine. Have you seen that before?

      In any case, I see that using the Cyclone is the way to go. If you have any thoughts on that issue during the module erase, let me know. Thanks!

      Ian

      • Greetings,

        I am glad you were able to get the cyclone working. Problems with erasing is usually due to power, but you mentioned that retrying it worked so that does not make sense. Is this problem consistently happening? Or was it a one-off problem?

        Are you using any custom ribbon cables, adapters, or unique hardware in your setup that I should know about?


        Takao Yamada

        • Takao,

          I'm not using any custom cables - just the ribbon cables that come with the programmers. It was a one-off, at least so far.

          Do you happen to know what the maximum current output is when using the Cyclone internal power? I would be very surprised if the limit is being approached, I think the most current I've seen the card draw in this state is 52mA (at 3.3V). The MCF51AC256 can run as low as 2.7V, so I think things should be ok from a power perspective. But I'll keep an eye on it in any case.

          Ian

  • Greetings,

    The amperage maximum is 0.5A, which is plenty for almost all applications.

    If the issue does not show up consistently then there is nothing to worry about. Sometimes you may need to restart the process and it may resolve itself. If it becomes a nagging problem, please create a support ticket on Support Page -> Support requests and we can try to resolve more technical and board-specific problems there.


    Takao Yamada

    • Thanks Takao, much appreciated!

      Ian

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