Search Results

Search results 1-9 of 9.

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

  • Hi, I have another issue with the Jlink driver. When modifying the content of the Flash memory through the embeddedStudio memory viewer, the flashloader starts to operate. However in this case, the flashloader code is not loaded into the working RAM resulting in having security exception due to illegal instruction. Here attached is a jlink log. - From line 245 to 280 we can see that the driver operates properly when loading the code. Especially we can note a Preparing RAMCode in line 250 and a D…

  • Using Jlink Flash v8.10e, I'm not able to do anything as the software is not able to halt the core. Looking at the code it looks the JLINK_GoIntDis function is not working. Part of trace : T272C 314:597.888 JLINK_GoIntDis() T272C 314:600.768 - 2.903ms T272C 314:600.800 JLINK_IsHalted() T272C 314:601.216 - 0.422ms returns FALSE T272C 314:601.280 JLINK_IsHalted() T272C 314:601.536 - 0.260ms returns FALSE T272C 314:601.600 JLINK_IsHalted() T272C 314:601.888 - 0.298ms returns FALSE T272C 314:601.952…

  • Hi Using Jlink probe with Visual Studio results in having inconsistent memory information during debug. The jlink driver is always returning data from the cache on a read memory command. Not the real memory content from the device. So it is impossible to use the jlink to debug issue related to flash memory content. A read memory command should always access the real memory content and not use the driver cache whatever the memory type is. Jlink driver version 8.10c. Regards

  • Additionnal information : The exception occurs for all exit conditions so for "step into" too. Exceptions occurs when attempting to execute flash loader code that should be loaded into RAM memory. mcause register indicates an illegal instruction at start address of SEGGER_FL_Erase. The exception results in having PC into the security exception handler. That's why I get the following message after modifying the memory: PC of target system has unexpected value after erasing sectors. (PC = 0x000001…

  • Hello Simon, I've just tried the new version. It does not work on my side. When using the memory viewer to modify the memory, it looks the flash loader is not loaded into RAM memory before calling it, resulting in having an illegal instruction error with address in loader. [Update] The exception does not occurs when doing a "step into" after the modification. Doing a "step over" or a run after cause the illegal exception occurs. And for step over I get the error message "Failed to set stepover b…

  • Hi Alex, Any news about the solution ? Regards, Fred

  • More information about the issue: When using the memory viewer of embedded studio to modify some bytes of the memory, only modified characters are updated into the cache used for flashing. That is visible in the jlink control panel and llink log file. However the first modification MUST trig a refresh of the cache by reading the full content of the concerned memory sector. This seems not to be done. As a result, the jlink flash driver does not know the current memory content of the sector and so…

  • When Jlink performs flash updates, it looks that its cache is not up-to-date if the memory content has been modified by code execution. It results in having wrong memory content at the end. My use is case is the following : My application is initializing 16 bytes at defined address of the Flash memory at startup, assuming the first byte is FFh. - 1. Flash code -> memory is virgin -> All bytes are FFh - 2. Using memory viewer, I modified some bytes (lets say 8th and 12th to CCh) into the buffer. …

  • Hi, I have an issue trying to upload a code lower than the Read Modify Write threshold. In this case the new code is not loaded. It looks that Modify step is not performed. I have custom RISCV device. I'm using Jlink tools 7.96e (same issue with 7.96j) The issue is seen when using Jlink direct driver or JLink with GDB Server. I have modified my custom flash loader to force the write (by making the verify operation returning false). Debug shows that the code sends to the device is the former one.…