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
Rare, undocumented error after reading memory of MPC5643L with UnitPPCNexus.dll
Jan K. Jan 29, 2016 at 03:39 AM (03:39 hours)
Staff: Takao Y.

  • Hi,
    sometimes, we get a very hard to reproduce error reading memory of a Freescale MPC5643L using the UnitPPCNexus.dll. We use both the Rev. A and Rev. B of the Multilink FX debugger. So far, the error only happened with the Rev. A.

    We use "read_data_long" to read memory, and always call "check_critical_error" to test for success. Very rarely, we get back a value of 3 (0b00000011) or 35 (0b0100011).
    Bits 0 and 1 are documented as:
    > Bit 0: Not ready response from chip - try a RESET.
    > Bit 1: Bus error occurred while reading/writing memory.

    Bit 5, however, is undocumented. What is the meaning of this error bit?

    Also, is there any way to recover gracefully from these errors without a hard reset of the target? After these errors occur, all subsequent calls to UnitPPCNexus return garbage.

    Lastly, any idea why these errors can occur? In the past, we also got errors with "Bit 5" set, and managed to avoid them by disabling the EE (external interrupt) bit of the MSR of the MPC5643L before reading memory (and other operations, for example single stepping) like this:

    > msr_val = get_msr();
    > put_msr(msr_val & 0xFFFF7FFF); // Disable Interrupts
    > val = read_data_long(addr);
    > put_msr(msr_val); // Restore MSR again

    This does not seem to help for this problem now.
    We have also tried to lower the shift speed to 1.25Mhz, but this has not helped either.



  • Greetings,

    Are you reading any unimplemented memory? Another time we have seen similar problem is if you are looking at memory where a module has not been clock gated yet.

    Is this happening at the same location in your code? Or randomly anytime the read_data_long is called?

    I will look into the other error bits to see if there is more information.

    Takao Yamada

  • This seems to happen randomly. We only read a small number of memory locations, but many times in the same session. One error happened on a memory location that was read >1000 times successfully before, in the same debugging session.


  • Greetings,

    The 6th bit (or 5th bit if counting from 0th), is an error due to not being able to communicate to the P&E hardware. Either something like firmware updating failed, or the device is busy. This is probably why you are no longer able to function after you get this rare error.

    Concerning gracefully recovering you may need to implement some error handling. if you already lost communication to the P&E hardware you can try reset_hardware_interface(). But any other errors, you may need to call force_background_mode() again to do a hard reset of the chip.

    The rev A and rev B are actually pretty different inside in hardware and firmware. This is why it does not surprise me that this problem only occurs on one and not the other.

    Takao Yamada

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