Search Results

So the output from SeggerGDBServer when it happens Reading all registers Performing single step... ERROR: Could not read FreeRTOS thread count from target. Reading all registers Read 4 bytes @ address 0x202122D0 (Data = 0x00000000) Removing breakpoint @ address 0x202104CC, Size = 2 Removing breakpoint @ address 0x2021229A, Size = 2 Reading 64 bytes @ address 0x20007FC0 WARNING: Failed to read memory @ address 0x00000000 <-------- I don't know why it's reading at this address, it's outside of sco…

Target: M4, SoC iMX7D V6.34b I can get the target hard locked followed by JLink resetting entire SoC .. Exact steps I'm not sure of, but it's single stepping a piece of code. When stepping, suddenly I get many cannot access memory ... errors. After which I have to kill my JLinkGDBServer. A subsequent attempt to re-connect to target leads to JLinExe or GDBServer giving error: ****** Error: Bad JTAG communication: Write to IR: Expected 0x1, got 0xf (TAP Command : 10) @ Off 0x5. Could not find core…

Hi Nino, Will try your process, from the doc I didn't think File.Load will just hook up the symbols without uploading it to target (which musnt' happen in my setup). Will comment on how it goes.

How can I do this : I want to load symbols _only_ for debugging , without programming target / any code upload? So in essence the target is running already with debug code on, I just want to attach to it, using a fix hard memory location. I can setup and break at the right place, but cannot figure out how to upload symbols only with Ozone.. (So what I want is what GDB does with symbol-file ... bla location )

I see, But it is a little odd, as I don't think I ever saw other such tool which would loose these breakpoints. Say Eclipse : I don't see it loosing any break points, especially those that are not affected. (Say, break point at line 10 in main still stays at line 10 after any number of rebuilds ... ) Thanks

At the moment I only tried Ozone and JLinkExeCL at the same time. This is what Ozone seems has trouble with, doens't allow JLink commander connected , to the other core.

Hi, Note that I noted that in _some_ cases you get this issue. So I wouldn't expect you to hit every time the problem. I also noted that , from your screenshot, you don't seem to be using Segger provided JLink connect script ? - NXP_iMX7D_Connect_CortexM4.JLinkScript. I see you select the device in the command shell. In my connect I use the script - NXP_iMX7D_Connect_CortexM4.JLinkScript. I don't specify -device as you do, I just put Cortex-M4. ( as the script handles device connection anyway ..…

But does Ozone support multi-core debugging ? Feels like that app sets a lock on the JLink ..

I think, the problem here is that it's lost the original break point which was set originally when project was loaded , before elf update. Why would one want to loose any setting at all just because the binary was re-built? IMHO it's not correct to loose any break points, or any actions attached to them..

Ozone 2.56.12 . You have set & attached commands to a bkpt in your project with Break.SetOnSrc, and Break.SetCommand. This works on project load. If elf file been re-built, and Ozone asks you if you want to reload it and you do, the command for the bkpt is lost and you have to re-load the project.

I'm on JLink V632b, target iMX7D, on M4 core. On some cases when trying to connect with JLink the device gets totally hardlocked, seems followed by SoC reset, with halt of main core, and total deadlock / not able to connect to target anymore with JLink. I see this trace: J-Link: Bad JTAG communication: Write to IR: Expected 0x1, got 0xF (TAP Command : 10) @ Off 0x5. Could not find core in Coresight setup After this I have to full reset the board. Any help on this ? JLink trace log : J-Link: Devi…

Is this possible? Yesterday I observed that, I can , using Segger GDBServer , connect & start debugging on one core , while, it seems ( as I'm not convinced ..) , I could also _same_ time, fire up JLinkExe and connect using same JLink to the other core, and do things like Halt & Go that other core, while still being able to debug through the GDBServer connected to the main core .(=one I'm busy with). This seems what I would expect & is awesome, but . . When I tried do this with Ozone (because it…

Hi Nino, Sorry a bit delayed reply ( I was actually polling this thread yesterday xN times, but was carried away with testing .. ) Yes upgrading removed this issue. Thank you

On iMX7D, JLink v630k. Upload code & start successfully, and single stepping. At some point GDB / Segger GDBServer spits this Remote failure reply: EC1100200000000000000000EC1100209C030020A5A5A5A5A5A5A5A5D8110020A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5A5D81100205D292120842F212000000041 ... 02-00000000-00-00266079-0051: T8C977700 266:079 JLINK_ReadReg(FPS31) returns 0x00000000 (0000ms, 2054ms total) 01-0000000D-00-00266080-008C: $EC1100200000000000000000EC1100209C030020A5A5A5A5A5A5A5A5D8110020A5A5A…

I'm on iMX7D, FreeRTOS v8, Segger J-Link package 6.30k I got this problem happens too often when I try to start the debug session, making me retry many times . After code upload & some initial setup (like register read, bkpts, ), the GDBServer app crashes/segfaults, and dumps core. (emailed to Segger .. ) From the traces on the system, and from the fact that disabling the RTOS library loading from GDBServer command line (remove -rtos) results in the problem going away . .(at least I haven't caug…

Quote from DaveHarper: “I looked at minidump-2-core but I don't think it would do anything more for me than WinDbg did. Like you pointed out, without the debug symbols there's not much of a chance to figure out what's going on. My only hope at this point is that Segger is able to come up with something in the dump file I sent them, or that a future release of either emStudio or Mint somehow resolves the problem. Dave” I'm curious, can WinDbg deal with the dynamically linked executable for Linux …

Thanks Nino. Did it make it into the upcoming release? Issue closed.

Hi Nino, Thanks for that list. Coupled with the other discussion we had under J-Link forum, my thread on incomplete RPM spec, this issue is exhausted now and can be closed. I still believe Segger needs to fix the RPM specs, so that packages can actually be installed correctly out-the-box. Regards

I would use minidump-2-core on their Linux dumps, and stay on Linux. With gdb on host. I'm not sure you would trace much without Segger giving you the debug symbols though. .. I think.

The required DDR (and other SoC init) can be requested from NXP directly, through support request. This been done before. (Or copied from provided U-boot init in the supplied BSP, if any.)