[SOLVED] DEBUGGING doesn't work in external RAM, but in internal RAM

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Hi,

    sorry for the delay in response.
    I could reproduce this behavior.
    I will try to provide you with an explanation / solution to this issue tomorrow.

    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Hi,


    I forwarded this issue to my collogues, but they are currently totally booked, probably until the end of this week.
    Sorry :(

    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Hi,

    we had a small time window on Friday evening to look at this issue.
    At first glance, it seems like a problem in the silicon(CPU still reads the Breakpoint instruction, presumably of a cache, while the J-Link DLL reads the original instruction from memory). Unfortunately, we had 4 engineers call in sick today, therefore further investigation(initially scheduled for today) has been delayed.

    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Hello David,

    the i.MX SoloX features a Freescale specific memory controller called LMEM that features two Freescale specific cache controllers. (Named Code cache controller and System cache controller)
    The System cache controller caches all memory addresses > 0x20000000, therefore it also caches the external RAM.
    The J-Link sets breakpoints in RAM via the Cortex-M specific AHB (background memory access). This enables the J-Link to set soft BPs w/o halting the core.
    But this bypasses this cache. Consequently, this leads to erroneous behavior.
    For example, in your case, the BP is cleared, but the CPU stills reads the cached breakpoint instruction, while the J-Link reads the restored original instruction .

    Internal RAM and Flash are not affected by this issue since the Flash has its own cache controller and the internal RAM is not cached at all.

    The simple solution would be to use Hardware breakpoints, but this is not possible, since Cortex-M4 specification allows hw. BPs only for the range of 0x0-0x20000000, hence the external RAM (0x81000000) cannot be used with hw BPS.

    Long term solution from our side: We will implement a special handling that clears and disables the cache before a J-Link accesses a cachable memory address, and enables caching after the access.
    Short term solution: You need to disable the System cache during debugging:
    (e.g in J-Link Commander:)
    w4 e0082000,0 (=> disable Code cache[0x0 - 0x20000000])
    w4 e0082800,0 (=> disable System cache[0x20000000 - 0xFFFFFFFF])

    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Hi Niklas,

    Thanks for your answer. I have some remarks:

    1- Are you sure registers are located at addresses 0xE0082000 and 0xE0082800?
    Because the iMX6SX refrence manual indicates the LMEM controller registers are located at 0xE0002000 and 0xE0002800.

    2- The LMEM controller is disabled at boot and is not enabled by U-Boot. So, I'm not sure it has
    any effect. Did you try it on board? (I didn't have time to check on board, will have some time
    on next Monday or Tuesday).

    3- When do you plan to do a release of the JLink software and/or probe firmware?

    Best regards,
    David
  • Hi David,

    Because the iMX6SX refrence manual indicates the LMEM controller registers are located at 0xE0002000 and 0xE0002800.

    We also noticed that, but this seems to be a typo in the manual, since this addresses collides with Cortex-M private peripheral registers.
    We compared the manual to other Freescale manuals and found 0xE0082000 and 0xE0082800.

    Did you try it on board?

    Yes, we did. If you cannot reproduce this, I can do it again and provide you with screenshots.

    When do you plan to do a release of the JLink software and/or probe firmware?

    There is no planned release date yet.

    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link
  • Hi David,


    Good to hear that you are up and running.


    Best regards,
    Niklas
    Would you like to be added to the J-Link software update notification list, so you get informed automatically when a new version becomes available?
    Just write me a PM or in case you want to subscribe to it yourself, please use this link: Link
    Notification for J-Link, J-Link Debugger, SystemView & J-Scope: Link
    Notification for Embedded Studio: Link