J-Link GDB debugging fails on NXP i.MX7 Cortex-M4 when running from OCRAM with cache enabled.

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

  • J-Link GDB debugging fails on NXP i.MX7 Cortex-M4 when running from OCRAM with cache enabled.

    Hi,

    We are developing an application for the Cortex-M4 core on the NXP i.MX7 using Exclipse + gcc + GDB + J-Link.

    Our plan is to run the M4 application from the OCRAM memory since the TCM memory is too small for our final application.

    When we build the application to not not enable the cache everything works and we can load, execute, single-step and set break-points.

    But when we enable the cache it does not work. We can still load the code and execution stops at the start of main():
    Setting breakpoint @ address 0x2020495C, Size = 2, BPHandle = 0x0001
    Starting target CPU...
    ...Breakpoint reached @ address 0x2020495C
    Reading all registers
    Removing breakpoint @ address 0x2020495C, Size = 2
    Read 4 bytes @ address 0x2020495C (Data = 0xF7FFB507)
    Reading 64 bytes @ address 0x20204940
    Reading 64 bytes @ address 0x20204980
    But if a single-step is performed or if the execution is resumed the GDB console just outputs the three lines below endlessly and the target does not execute:
    ...Breakpoint reached @ address 0x2020495C
    Reading all registers
    Performing single step...
    ...Breakpoint reached @ address 0x2020495C
    Reading all registers
    Performing single step...
    ...Breakpoint reached @ address 0x2020495C
    Reading all registers
    Performing single step...
    ...Breakpoint reached @ address 0x2020495C
    Reading all registers
    Performing single step...
    If we download the application with cache enabled to the eMMC memory and start it from U-Boot it works as expected without any issues.

    Any ideas?

    Thanks!

    /Niklas
  • Hello Niklas,

    Thank you for your inquiry.
    Such an issue is not known to us.
    Which iMX7 are you using exactly?
    Here is an overview of our currently supported devices: wiki.segger.com/IMX_Series_Devices
    Are you using custom hardware or an eval board?

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hello,

    We received no answer from the customer so we have no information if that has been resolved for Niklas.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • SEGGER - Nino wrote:

    Hello,
    We received no answer from the customer so we have no information if that has been resolved for Niklas.
    Best regards,
    Nino


    Hi Nino,

    Do you have any solution for this, or can you confirm the problem?
    I reproduce the reported issue, by enabling / disabling cache for the memory in question. (Also, as I reported to Segger support, it's same issue without GDB, but with Ozone )

    I've seen other reports that, it seems, ARM's D-Link debugger does not have similar issue with the cache enabled / not.

    The post was edited 1 time, last by v01d ().