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: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      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 contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • 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: Forum Rules

      Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
      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 contact us per e-mail.
      The following contact form can be used for this: Contact Us

    • 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 ().