Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
PROGCFZ detects incorrect chip, can't load algorithm
Nathan K. Mar 27, 2015 at 03:19 PM (15:19 hours)
Staff: Takao Y.

  • I have a MCF5206e based board with an SST_vf200a attached that I have programmed many times with PROGCFZ and a Multilink Universal. After the last programming cycle, I have been unable to program it again. 

    When I open PROGCFZ, the chip is incorrectly detected as a "5280_81_82", where before this last programming it was detected as "Generic 52xx". Other boards, where the latest code has not been downloaded, are still detected as "Generic 52xx".

    When I try to load the programming algorithm, it fails with:
    Error loading .CFP file : C:\PEMicro\PKGCFZ\Algorithms\SST_39VF200A_1x16x128k.CFP at address 80000000

    This makes sense, since RAMBAR is at C04 in my 5206e CPE, but is at C05 on a 5280, which means that the memory mapping is likely not taking place.

    Again, this used to work until the latest version of my code was programmed to the chip. The board is running that code fine, and I can still connect with ICDCFZ. ICDCFZ also detects the incorrect part, but still is able to examine memory, etc.

    Is this possibly a bug in the chip detection routines? I do not want to try programming another board if I will be unable to connect to it afterwards. Is there any way to just tell PROGCFZ that it is a "Generic 52xx"?

    Thanks,
    Nate Koflanovich




    Comments

  • Greetings,

    1) Are you using the coldfire synchronous cable when working with the MCF5206e?

    2) It does sound suspicious that the detected chip is now different and that it can no longer load an algorithm. Is code change the only thing that is different? Nothing new in hardware or new software? This problem usually occurs when the P&E interface is not able to communicate to the chip very well, meaning it is usually a hardware problem, not software.

    3) Try lowering the debug shift frequency and see if this improves the situation.

    4) Start monitoring the RESET line. Not being able to detect the right chip and not loading the algorithm means the chip is probably stuck in RESET or RESET is toggling due to a watchdog, your code not handling a interrupt, or illegal instruction was reached in code.


    Takao Yamada

  • Hello,

    I do have an update on this, but first to reply to your 4 points:

    1. Yes, I am using the synchronous adapter.

    2. Nothing else changed - I literally just added more code to the application. I never even unplugged the cables. And the whole time, ICDCFZ is able to run, read memory, etc, even though it detected the incorrect chip.

    3. I tried different frequencies all the way from slowest to fastest, and it made no difference. Really I tried messing with all of the options.

    4. The application loaded is running and stable - definitely not in reset or hitting any error vectors. All of those cause a halt in my application right now, and I am not getting halts or resets.

    Now, I did make some progress to trick it into working again. I edited the algorithm file and added:

    CONTROL=80000001/0C04/

    to force it to set RAMBAR on this chip. It was probably still writing to 0C05 too, but that's an invalid location on the 5206e, so it probably didn't really matter. After I did this, I was able to program it again. Both PROGCFZ and ICDCFZ continued to detect the wrong chip, but both were usable otherwise (of course, I don't really know what else this could affect).

    This morning, I made additional firmware updates, and it has gone back to detecting "Generic 52xx". Again, no changes other than the firmware image.

    It's definitely strange, but it makes it really seem like there is some link between the memory contents and the chip id algorithm. In any case, I do have a workaround, so I expect to be in good shape from now on.

    Thanks,
    Nate Koflanovich

  • Greetings,

    Thank you for reporting your findings. When grabbing an external algorithm from our algorithm listings, they are only default settings. They need to be modified to fit your board's needs. So if you want to change MBAR to a different address then it is important to set that within your algorithm.

    Here is a quick tip on external flash:
    https://www.pemicro.com/faqs/faq_view.cfm?id=121

    http://www.pemicro.com/blog/index.cfm?post_id=29


    Takao Yamada

  • Hello,

    I am not actually trying to change the RAM address - it is still at 0x80000000, as defined in the begin_cs line in the algorithm. It was just that PROGCFZ writes to the wrong control register (because it detects the wrong chip) so I am just forcing it to also write to the correct one for this instance. Without doing this, PROGCFZ never actually sets RAMBAR, making it invalid since a reset clears the valid bit.

    The standard algorithm worked fine up until one build of my application, and has worked for every build since, with no changes to the hardware or addressing.

    -Nate Koflanovich

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