Search Results

Hi, Nope. Priorities have been changed regarding this. We may add native support in Q1 2017 but we can not promise this schedule right now. If you need urgent support, we would recommend to add support on your own using the SEGGER OpenFlashloader. Further information regarding this can be found here: wiki.segger.com/Adding_Support_for_New_Devices Best regards Erik

Hi, What target device do you have in your setup? Do you use custom hardware or an evaluation board? According to the output, you are using an older version of the J-Link software (V5.12e). Do you see similar behavior when using the latest version from our website (V6.12a)? segger.com/jlink-software.html Best regards Erik

Hi, Can you please send us a J-Link log file of a session where the issue pops up and provide us with the information in which area no data have been programmed although they should have been programmed? HowTo enable the J-Link log file? wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File Best regards Erik

Hi Matthew, Basically, the LED means reset is active on target side (== LOW). Best regards Erik

Hi, We are able to reproduce the described behavior. We are currently investigating this and plan to have a fix available by the end of this week. Best regards Erik

Quick follow up: Please use the latest version V6.12a for your tests. Best regards Erik

Hi, For SAM4E devices, a GPNVM bit must be set to boot from flash. Default is boot from ROM. In general, the J-Link software sets the GPNVM bit to boot from Flasher when programming the internal flash. However, according to your description, it seems like the GPNVM bit is set correctly to boot from flash (as the device boots correctly from flash after power-on-reset) but it seems like the boot selection is not taken into account after a power on reset but not after a ordinary core reset. The SAM…

Hi, Can you please create and upload a J-Link log file of the IAR EWARM session? How to enable a J-Link log file in IAR EWARM?: wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File Best regards Erik

I double checked the source code and reset type 2 also performs a reset via reset pin toggling so it should work in the s ame way as when using "r1" and "r0". However, as you wrote you can not test it anymore, we consider this case closed. Best regards Erik

Hi, Quote: “So what is the different way to do that ? how do i disable the readout protection / the option bytes ?” As Alex already described, the unlock sequence is described in the ST "Programming Manual" for your used device / series. The documentation can be found on the ST website. Example for the STM32F2 series: st.com/content/st_com/en/suppo…ceType=programming_manual Best regards Erik

Thanks for the udpate and confirming that this is solved in the latest version of the J-Link software. Best regards Erik

Hi, Quote: “Anyone know anything about halting issues? ” Seems like in GDB Server you perform a reset instead of a halt. Most probably, the reset command will not work in J-Link Commander as well. Why? For iMX53, a special reset is required which is not implemented yet and can not easily implemented because it may differ from setup to setup because it depends on the boot source. Therefore, we recommend to the reset on your own using a J-Link Script file so it fits your requirements. Further info…

Hi, Quote: “Newest file in RAMCode_SDK.zip is readme.txt from 2010-08-31.” This is the latest / current version of the RAMCode SDK. Quote: “Is there a newer RAMCode SDK that has an example of for example RAMCODE_CMD_CHECKRAM implemented?” CHECKRAM is part of the generic RAMCode part which is included in the J-Link DLL and merged with the specific ramcode (the one created using the RAMCode SDK) during run time. Therefore it must not be implemented manually. In general, all files are included in t…

Hi, Did you give the "-min" command line option a try in J-Flash? It should already do what you are looking for. Apart from this, the pop up can be disabled using the J-Link SDK. Further information regarding the J-Link SDK can be found here: segger.com/jlink-sdk.html If you are interested in the J-Link SDK, please let me know. Best regards Erik

Hi, We have fixed something which causes the described behavior in V6.10n of the J-Link software. Extract from the release notes: - DLL: Under special circumstances, flash programming did not work for NXP (Freescale) KL82 series devices. Fixed. Updating to the latest version V6.12a should already solve the behavior you are seeing. Can you please quick check and confirm this? The latest version is available for download here: segger.com/jlink-software.html Sorry for any inconveniences caused. Bes…

Hi, There most be something different in your setup / sequence if the behavior changed. Quote: “Now, When I select the CPU without security the the hex file works after programming. But if I select the CPU with security then the hex file fails to start after successful programming.” Just to make sure that we got you correct, can you please confirm that in both cases the file has been programmed successfully? Can you please send us the data file? Does the application start after performing a powe…

Hi Keith, Quote: “When we connect to the STM32L011 chip, the chip is driving the SWD clock pin (PA14) as an output after reset. We have a pull down resistor on the pin, but the CPU is pulling the signal high. When we try to program the part, the CPU is pulling it high. I have one CPU that is working properly and 9 that are not. I have never programmed the CPUs that are failing.” Sounds strange. Virgin devices do not change the pin function of the debug interface signals PA13 and PA14 (see extrac…

Hi, Did you gave the "RSetType <Type>" command a try (example "RSetType 2", followed by "r") For Cortex-M / JTAG, resettype 2 is reset via reset pin which should be similar to the manual reset pin toggling (via "r1", "r0"). Apart from this, you can override the reset sequence used by the J-Link DLL using J-Link Script files. They also allow to perform the manual pin toggling using the "JLINK_JTAG_ResetPin = 1" or "JLINK_JTAG_ResetPin = 0" commands. For further information regarding this, please …

Hi, Current versions of the J-Link DLL already supports detecting of secured STM32L0 devices. Once a secured device has been detected, the DLL offers to unlock it using the mass erase sequence. Therefore, can you please give the latest version of the J-Link Commander (V6.12a) a quick try and provide feedback / upload a screenshot of the entire J-Link Commander output? Regarding the STM32 unlock utility: I will add this on our todo list but right now, we are quite busy with other open projects an…

Hi Francois, We plan to have a solution ready within the next two weeks. Please note that if the u-boot prevents the J-Link to establish a debug connection (e.g. by disabling the debug interface, re-configuring the debug pins, disabling clocks, enabling low power modes, etc...) there is no possibility to establish a connection. Would you like to be added to the J-Link software update notification list, so you get informed automatically when the new version becomes available? Subscribe: segger.co…