Search Results

Search results 1-20 of 202.

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

  • JLinkExe unwanted GUI

    v01d - - J-Link/Flasher related

    Post

    Quote from SEGGER - Fabian: “I will send you a link with a preliminary version for testing purposes via PM. ” I tried it, and the problem now was the Accept License terms dialog / message box. Firmware update window suppression worked.

  • JLinkExe unwanted GUI

    v01d - - J-Link/Flasher related

    Post

    Quote from SEGGER - Fabian: “The only thing that changed is that we added GUI support for Linux, ... b) We will add a "-nogui" command in our next release. ” But this sounds excellent. Thank you So as to set a reminder to upgrade : which release number / version will be next ? (Btw, Linux is what all embedded sw dev work must be on ^__^ )

  • Hey Erik Quote from SEGGER - Erik: “Basically there are two possibilities: ” This is great stuff, thank you. Yes I was thinking along the route of setting hardware address watchpoint at address X. One obvious non-nicety is too much knowledge at the connect/reset script stage (sits below all code & debugging). I understand your easiest solution, and I see how it can work. (Just that you would need to modify all your early startup code). I may, however, ask you to check something else I'm using, h…

  • Hello, Now I have sent you an archive containing the setup exactly as I use to create this problem / trace (there is nothing more to it beyond it, its complete). I described exactly how I start it in the README, and the logs are from it essentially ( I didn't repeat them, but they the same).

  • Hey Erik Quote from SEGGER - Erik: “....... If the core is hold in reset after triggering the reset, the ResetTarget() has to release the core and halt it. It does not make any sense to return from ResetTarget() if the core is not accessible through the debug interface. ............. Even if the DLL does not check the debug registers after resettarget, what should the DLL do? It still cannot access the core so a debug session or whatever will simply crash. ” Thanks for quick response on technica…

  • JLinkExe unwanted GUI

    v01d - - J-Link/Flasher related

    Post

    Because this was new JLink software, on the first JLinkExe run immediately FW update dialog popped up, which thus started this thread. I immediately killed the app, and starting looking into how I can avoid these dialogs. My setup is Linux x86_64 (Fedora based). Thus the first thing I want: how to suppress this update dialog _immediately_ before you can do anything else - that is, before it (JLink) even thinks to pop-up anything. Thus I tried to pass this as commands to be executed - on startup.…

  • Quote from SEGGER - Fabian: “Hi, Could you please send us a J-Link log file? How to enable: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File ” I have messaged you the logfiles through the forums's message box - please see & let me know if you got it.

  • Quote from SEGGER - Fabian: “Not necessarily. Depends on the previous / current state and upcoming actions. Quote from v01d: “How does it check it exactly ” Depends on the device (core) you are using. Usually by reading the debug registers. ” Is there way to plainly prevent whatever calls the script's ResetTarget() from checking the CPU's debug registers after ResetTarget returns? And stop trying to halt it? If on a platform / SoC, the system may implement it's own proper core or sub-platform re…

  • I need to have a special ResetTarget() in my JLink script file. From the manual, it says, If this function is present, it will be called instead of the DLL internal reset. It also notes that, limitation is, DLL expects target CPU to be halted / in debug mode when leaving the function. Does this mean DLL still will check if the target CPU is halted after my custom ResetTarget is executed? How does it check it exactly? I have my ResetTarget doing what I need, and returning always 0 (return 0;), wh…

  • JLink package v670g. Starting GDBServer with freeRTOS pluing on , i get error trace : ERROR: FreeRTOS thread count is unreasonably big, not proceeding. Now, I cannot say my previous Jlink V652e had the issue, and FreeRTOS plugin was working fine, using same code both versions. Also, before this error it traced : Source Code (17 lines) What is the issue then that I get the thread count error trace above ?

  • JLinkExe unwanted GUI

    v01d - - J-Link/Flasher related

    Post

    The GUI constantly interferes with operation - starting with asking to update firmware. Passing exec SuppressControlPanel doesn't work; Requires to further pass exec SupressInfoUpdateFW. One would hope that, passing above two, and then doing exec SilentUpdateFW, would avoid the GUI , but NO. .. While updating it yet another dialog pops up with progress... How to avoid all these windows ..?

  • JLinkExe unwanted GUI

    v01d - - J-Link/Flasher related

    Post

    In the new version what previously was only command line / console is now seems by default invokes some JLink GUI server and causes unwanted Window popups. What is the proper way to disable this behavior, and keep to the old proper console only app as it always was? The only non-proper - as I see, because you modifying install - option is to remove all execute permissions on that GUI Server app.

  • I saw on this thread forum.segger.com/index.php/Thread/7026-SOLVED-iMX8QX/ That iMX8QX JLink support - if I understood correctly - is implemented by NXP. Does this mean all Segger JLink support for NXP products, any chip/SoC, from now is handled by NXP..?

  • Quote from Masmiseim: “But you have to use multiple instances of the Application; one for each core. ” If we take say lowest Application involved here, for me that would be Segger JLinkGDB, then yes exactly, one per core. (one JLink hw for all target cores). Quote from Masmiseim: “Accessing multiple cores within a single instance of the Application is not possible as far as I have understood it. ... ” Ok, then we on the same page length , I think. I think, JLinkGDB not supporting multi-core per …

  • Quote from SEGGER - Fabian: “I added a section covering this in the article about this board in our Wiki: wiki.segger.com/CC3220_LaunchP…ith_JTAG-.2FSWD-Isolators ” Hello, I double checked and no, your indicated solution on wiki doesn't seem to solve it for me. In my setup, I apply external 3.3V to the target, refer J22 - external supply. This can be separated from the emulator's side of the board, so that i has it's own supply - refer J19,J17 (VBAT, BRD), cross them to put target on separate su…

  • Quote from Masmiseim: “ Quick answer: No it is not possible. ” Hi Masmiseim, I do not think I understand you. Because, I _can_ connect & debug multi-core (multi ARM A core) to be specifically, on a SoC I used. Not only that, but with single JTAG I can connect to 2 A cores (SMP config) and one M core at the same time (for AMP thus). Effectively , I can have 3 simultaneous core debug with single JTAG & software. The problem is it does not integrate well with any higher level software tools I use. …

  • I've previously used Studio on Cortex M only. I see it supports Cortex A too. But does it support or integrate in a seamless way debug on multi heterogeneous cores? For example, debugging concurrently on A and M targets, in same running IDE instance. (Same JLink of course). Also, does it do in a seamless flawless way multi-core debug on symmetric A cores? What I would expect is, same instance IDE, same session running, ability to insert break-points in _single_ instance and not re-load per-core,…

  • Hey Fabian, will do asap with photo & details, but i'm on something else this week and/or few days.

  • Thanks Alex, On breakpoints Quote from SEGGER - Alex: “ Again: It has *nothing*(!!!!) to do with flash breakpoints. ” OK, I started that from : Quote from SEGGER - Fabian: “ One reason could be, if you have any flash break points enabled. ” .. and developed "theory". Revoked now, thanks for your explanation.

  • Fabian, Quote from SEGGER - Fabian: “In the beginning you are writing about an issue with the J-Link EDU ” Yea sorry for confusion : it is the J-Link EDU MINI that I _think_ /believe I have issue with, not J-Link EDU . ( The latter I used to re-test and , wrote that I don't observe problems with). Quote from SEGGER - Fabian: “1) The serial number of the J-Link you have issues with (as already requested before). Feel free to send it to me via PM. ” I PM'ed you asking if you still want my serials …