Tuesday, May 22nd 2018, 1:58pm UTC+2

You are not logged in.

  • Login
  • Register

Reply

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Message information
Message
Settings
Automatically converts internet addresses into links by adding [url] and [/url] around them.
Smiley code in your message such as :) is automatically displayed as image.
You can use BBCode to format your message, if this option is enabled.
Security measure

Please enter the letters that are shown in the picture below (without spaces, and upper or lower case can be used).

The last 5 posts

Thursday, April 19th 2018, 5:08am

by v01d

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.

Wednesday, April 18th 2018, 10:35am

by SEGGER - Nino

Hello,

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

Best regards,
Nino

Tuesday, April 17th 2018, 12:48pm

by v01d

NiklasG, Nino

Was this resolved ?? How. Please share, have the same , likely , issue. ;(

Thursday, March 15th 2018, 11:08am

by SEGGER - Nino

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: https://wiki.segger.com/IMX_Series_Devices
Are you using custom hardware or an eval board?

Best regards,
Nino

Wednesday, March 14th 2018, 4:26pm

by NiklasG

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():

Quoted

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:

Quoted

...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