Search Results

Search results 1-20 of 1,000. There are more results available, please enhance your search parameters.

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

  • Hello Alessio, Great to hear that you are up and running again. We will consider this thread a solved now. Best regards, Nino

  • Hello Alessio, The unknown register error message is an old Ozone issue and is already fixed in the latest Ozone version. Could you update to the latest Ozone and J-Link software version to make sure you do not see any issues appearing that are already fixed? Quote from ballotz: “Ok, any idea about when there will be full support? ” It is in our feature tracking system but currently we can't name a fixed timeschedule. Best regards, Nino

  • Hello, Thank you for your inquiry. Such an issue is not known to us. Do you see the same behaviour with the latest Embedded Studio version? segger.com/downloads/embedded-studio/ If yes, the issue seems to be reliably reproducible for you. Could you provide your complete project for reproduction purposes? What are the exact reproduction steps? Best regards, Nino

  • Hello, Quote from Tsungming: “I am not really sure the meaning of "we do not provide any support for the conversion to J-Link as stated in the guide.", so you means the board Cypress(spansion) S6E2CC can not directly develop on Segger Studio? ” No, it just means that if you run into some issue with the guide we are not allowed to provide support for it. Quote from Tsungming: “And my board is using a USB cable (A/micro-B) to connect the computer, so you means if I want to use Segger studio, I hav…

  • Hello Alessio, Could you give the latest J-Link software a try so we are not hunting some already fixed issues here? segger.com/downloads/jlink/#J-…twareAndDocumentationPack Do you see the same behaviour? EDIT: Quote from ballotz: “Our project uses a Winbond W25Q128JVSIM flash, QSPI, secondary pinmux. ” What does secondary pin mux mean here? Is it the same like on the NXP MIMXRT1060-EVK eval board? If not this would explain the behaviour as the flash loader will only work with exactly that confi…

  • Hi, Thank you for providing the logs. We will see if we can narrow down the issue that way. We will keep you posted. Best regards, Nino

  • Hello, Thank you for your inquiry. Such an issue is not known to us. Are you running on custom hardware or an eval board? If custom hardware, is the issue reproducible on an eval board? If yes, could you provide the example binary/hex file for the STM32F072 for reproduction purposes? Best regards, Nino

  • Hello, Thank you for your inquiry. It appears that the instrumentation of the FreeRTOS sources was not successful as your recording shows only Systick ISRs. I would expect at least one task to be running + the scheduler. Did you make sure that all necessary instrumentation steps have been applied? For more information see SystemView manual UM08027_SystemView. Best regards, Nino

  • Hello, Quote from Allen: “I can create a Template_CortexM.elf with SEGGer Embedded Studio, if is the .elf the "RAMCode"? ” Yes the resulting application is the RAMCode. Regarding the demo project for the STM32F469_Discovery board, please note that we can't share this sources in public. But you can request this via our support system. Simply open a ticket in the J-Link support group requesting the sources. How to open a ticket is explained in my signature. Best regards, Nino

  • Hi, OK that looks weird. It seems like it depends on the system fond used. Which host OS are you running on? I do not see this behaviour on Win10. Best regards, Nino

  • Hello, Thank you for your inquiry. Currently JFlashSPI will always first try to detect the Flash ID. This is to make sure that a reliable connection to the chip is established so no damage can be done. So unfortunately you would have to use your workaround in this specific case. Alternatively you can also purchase the J-Link SDK and create your own version of the J-Flash SPI that handles such special cases: segger.com/products/debug-prob…nk/technology/j-link-sdk/ Best regards, Nino

  • Hello Karsten, Thank you for your inquiry. Are you using custom hardware or an eval board? You can find an example project for the STM32MP15X-EVAL on our Wiki: wiki.segger.com/STM32MP15x#Tracing_on_STM32MP15x Could you give the TMC/ETB trace sample a try? Does it work for you as well? If not could you check the following troubleshooting steps and provide a screenshot of the Commander session? wiki.segger.com/J-Link_cannot_…the_CPU#Target_connection Best regards, Nino

  • Hello, Thank you for your inquiry. J-Link supports two programming modes. Direct and indirect. wiki.segger.com/Programming_External_SPI_Flashes If you want to do direct programming, all you have to do is to wire the SPI Flash to the J-Link debug interface as documented and you are good to go. The following Flashes will work automatically: segger.com/products/debug-prob…es/supported-spi-flashes/ Other similar Flashes can be added manually using J-Flash SPI: segger.com/products/debug-probes/j-link…

  • Hello, Quote from hs2: “Yes, I'm using the latest non-beta JLink package and also ensure Ozone is not running when installing JLink. ” Ok thank you for verifying. Quote from hs2: “No, as mentioned since it happens sporadically (and luckily not very often) I don't see how to provide a reproducible test case. ” Yes that is why we would like to investigate this further, but without a reproduction scenario that works on our developer PCs it is near impossible to fix this. To understand better what y…

  • Hello, Thank you for your inquiry. We received your request via our support system in parallel. To make sure no information gets lost between channels this thread will be closed now and the correspondence will continue via e-mail. Best regards, Nino

  • Hello Alessio, Quote from ballotz: “We noticed that RT106x processors are not listed anymore in JLinkDevices.xml (JLink in Ozone 3.20b). ” Yes this is intended behaviour as the QSPI flash loader is now compiled into the J-Link dll. Quote from ballotz: “Using NXP Boot Utility we found that probably the boot header got corrupted since it showed occasionally a zero sector size of the flash. ” Did you adjust your Ozone project as explained in your other thread? Missing RAM functions from Execution P…

  • Hello, Thank you for your inquiry. Sounds like Ozone sets the initial breakpoint on the first mention of main() in the elf file. We would like to look into this and improve Ozone if possible. Could you provide the elf file for reference? As a workaround you can set the initial breakpoint symbol in Ozone under Tools->System Variables->VAR_BREAK_AT_THIS_SYMBOL Best regards, Nino

  • Hello, Thank you for your inquiry. Try using __ARMCC_VERSION instead. We will update the RTT sources accordingly with our next software package release. Best regards, Nino

  • Hi, Great to hear that you are up and running. We will consider this thread as closed now. Best regards, Nino

  • Hi, that is also unwanted behaviour and will be improved in future versions. Best regards, Nino