Search Results

Hello, Thank you for your inquiry. You registered with a J-Link EDU but are using a company email address. Please note that the J-Link EDU may not be used in any commercial context as this would be a license violation and illegal. Could you clarify your situation here, why are you using the EDU model? Could you name your Embedded Studio license number for reference? According to the user manual for the MM32L062NT there is no EEPROM at 0x08006000. Could you clarify which manual for this device yo…

Hello, Thank you for your inquiry. Could you provide more information on what is not working? Could you provide a small example project that shows that behaviour? Best regards, Nino

Hi, It appears that the documentation is not accurate anymore. Sorry for that. You can find it in project options under Code->Build->Project Macros. Best regards, Nino

Hi, Thank you for your inquiry. When using the SEGGER Linker section macros are not needed as the SEGGER Linker offers more flexibility in the linker script itself so you can define symbols, regions etc. all in the script and thus have only one point of edit should things change. For reference the Linker manual can be found here: studio.segger.com/segger/UM20005_Linker.pdf How to switch from gnu linker to SEGGER Linker is explained here: studio.segger.com/segger_linker.htm As a base we recommend…

Hi AQ, yes, I understood you the first time around. Ozone offers a scripting interface for that. In this case you would use conditional breakpoints. You can do that either via the GUI, automatically in the Ozone project script, or manually in the Ozone Console window if you do not like to use the GUI. An example on how use user actions automated is shown here: wiki.segger.com/Automated_Tests_with_Ozone#Debug_example For more information see the Ozone reference manual. Best regards, Nino

Hello, Thank you for your explanation. Sorry I understood you incorrectly before. For such deployment setups you can use project macros the same way as you would use the global macros with the difference that it is saved on project level and thus protable. For more information see the documentation linked in my last post. Best regards, Nino

Hi, Thank you for your feedback. We will add this to our improvements list. Best regards, Nino

Hi, Thank you for your inquiry. The reported behaviour was reproducible and will be improved. A quick test through numerous Ozone versions shows that Ozone always behaved this way. Best regards, Nino

Hi, Thank you for providing the video. That you are watching Flash memory here is a crucial hint, J-Link caches the Flash content after a download. See here for more information: wiki.segger.com/Debugging_self-modifying_code_in_flash This leads to the effect you see here, as for the J-Link the Flash memory area was untouched by J-Link so the cache stayed untouched, so no need to update. When you "reopen" the memory window J-Link will do a readback. To avoid the caching you can disabled it either…

Hi, Thank you for your inquiry. The reported behaviour is reproducible and will be improved. Sorry for any inconveniences caused. Best regards, Nino

Hello, Thank you for your inquiry. For such a setup custom global macros can be used. You can set them under Tools->Options->Building->Global macros How to utilize the is explained here: studio.segger.com/ide_project_macros.htm So one setup could be that you set the APP_VER macro as global macro which then you can use as the CL argument for the post build step and pass it to another preprocessor define. That way both options will reference the same macro. Is this what you are looking for? Best r…

Hello, Thank you for your inquiry. Such an issue is not known to us. Could you provide a J-Link log file of the failing session? wiki.segger.com/Enable_J-Link_log_file How did you create the project that you are testing with? Did you use the project wizard to set up a new project? We recommend using the CPU support package for this: segger.com/products/developmen…o/technology/cpu-support/ Best regards, Nino

Hello Sam, Thank you for your inquiry. There is no conversion tool for the different script types available. For reference we recommend to create a new nrF52 project using CPU support package: segger.com/products/developmen…o/technology/cpu-support/ This will create a simple hello world example with a memory map and a SEGGER Linker script that can be used for reference. For more information see the linker documentation: studio.segger.com/segger/UM20005_Linker.pdf Best regards, Nino

Hello, Great to hear that you are up and running again. For completeness a general guide on how to use external toolchains with ES is explained here: wiki.segger.com/Use_an_externa…hain_with_Embedded_Studio This thread will be closed now. Best regards, Nino

Hi, I tried to reproduce the behaviour with the additional information but everything is working fine for me even after letting it run over 2 hours. It appears to be setup specific. Could you provide an example project that would run on some eval board with which the behaviour was reproducible with? Is the behaviour reproducible more often if you decrease the data buffer size for the data graph? Best regards, Nino

Hi, Great to hear that you are up and running again. Quote from maxl_1989: “One more question is it possible to see the STACK section also in the Memory Usage Window? I only can see the FLASH and RAM Segments (see atachment)? ” Currently not. But it is already on our todo list. Best regards, Nino

Hi, Thank you for your inquiry. The website is accurate. You get all debug features the J-Link PRO has with the J-Trace PRO + streaming trace capabilities. But the J-Trace PRO Cortex will only support Arm Cortex targets in all debug modes. This was a decision made to be able to provide a trace probe at this price point. If you require a probe with other cores supported than Arm Cortex cores you will still need the J-Link PRO. Best regards, Nino

Hello, I gave the project a try on a generic MIMXRT1060-EVK board with the QSPI Flash selected. However the application would not download properly with Embedded Studio. Is there anything I have to consider here for the reproduction project? How was your eval board set up exactly? Best regards, Nino

Hi, Thank you for providing the video. The behaviour was reproducible and will be improved. Best regards, Nino

Hello, Quote from icwiener: “Is this still planned for the future or made absolute on purpose? ” This is on purpose, but the reason is not Ozone. Rather the compilers output debug information in absolute paths usually. Ozone only works with the output file so if you move your elf file in your file system around without rebuilding the application, the paths will become incorrect and Ozone can no longer reference the source files to the code. That is on of the reasons why Project.AddPathSubstitute…