Difference between revisions of "Unlimited Number of Breakpoints in Flash"
(Created page with " By default, the number of breakpoints that can be set, when debugging in flash memory, is limited to the number of hardware breakpoints that are supported by the device. The...") |
m (Changed to use Template:Note) |
||
| (6 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
| + | By default, the number of breakpoints that can be set, when debugging in flash memory, is limited to the number of hardware breakpoints that are supported by the device. The number of hardware breakpoints being supported usually ranges from 2 (e.g. ARM7/9, Cortex-M0) to 6 (e.g. Cortex-M3/M4/M7). For devices where J-Link supports direct download into flash memory, it also supports setting an unlimited number of breakpoints when debugging in flash (further called unlimited flash breakpoints). For what devices flash download (and therefore also unlimited flash breakpoints) is supported, can be seen on our website: [https://www.segger.com/jlink_supported_devices.html#DeviceList Device list]. Unlimited flash breakpoints are available in different kinds of memory mapped flashes, be it internal flash, external parallel CFI flash or memory QSPI flash, as long as the flash supports direct execution of code (meaning it is read-accessible via the regular address space of the device). |
||
| + | == How do Unlimited flash breakpoints work? == |
||
| + | For more information about how the technique behind Unlimited flash breakpoints work, please refer to our [https://www.segger.com/jlink-unlimited-flash-breakpoints.html website]. |
||
| + | == Precautions when using DMAs in the target application == |
||
| − | By default, the number of breakpoints that can be set, when debugging in flash memory, is limited to the number of hardware breakpoints that are supported by the device. The number of hardware breakpoints being supported usually ranges from 2 (e.g. ARM7/9, Cortex-M0) to 6 (e.g. Cortex-M3/M4/M7). For devices where J-Link supports direct download into flash memory, it also supports setting an unlimited number of breakpoints when debugging in flash (further called unlimited flash breakpoints). For what devices flash download (and therefore also unlimited flash breakpoints) is supported, can be seen on our website: [https://www.segger.com/jlink_supported_devices.html#DeviceList Device list] |
||
| + | As using unlimited flash breakpoints means that the flash is reprogrammed by J-Link, some RAM buffer is temporarily needed by J-Link, during the flash reprogramming process. The J-Link DLL makes sure that original RAM contents are preserved before the flash programming and restored afterwards. |
||
| + | Please note that DMAs are usually not halted while the CPU of the device is halted and continue operating which will interfere with the flash reprogramming process if a DMA uses the same RAM area as the flashloader of J-Link does. Usually the first 2-4 KiB of the internal RAM of a device are temporarily used by J-Link during flash reprogramming. Please make sure that this area is not used by DMAs in case unlimited flash breakpoints shall be used. As a target device usually provides many different DMAs and their presence/absence heavily depends on the specific device type (even for the same series, smaller/bigger models may implement more or less DMAs), it cannot be supported in a generic way to pause/temporarily disable all DMAs during flash reporgramming. |
||
| − | unlimited flash breakpoints |
||
| + | == Limiting the temporary RAM buffer used for flash programming == |
||
| − | The J-Link software comes with an additional feature, called Unlimited Flash Breakpoints. |
||
| + | The J-Link DLL allows to limit the max. RAM area that is used during flash programming. This can be achieved via different options which are explained in the following. |
||
| + | {{Note|Setting the RAM limit impacts the performance of the flash programming speed. Setting the limit below 512 bytes is not recommended and may result in flash programming to not work.}} |
||
| + | === Via Command String === |
||
| − | Unlimited Flash Breakpoints allow the user to set an unlimited number of breakpoints when debugging in flash memory. |
||
| + | The J-Link DLL allows to limit the max. RAM area that is used during flash programming, via the following command string: |
||
| − | Without this feature, the number of breakpoints which can be set in flash is limited to the number of hardware breakpoints supported by the debug unit of the CPU (2 on ARM 7/9, 4-6 on Cortex-M). |
||
| + | SetRAMUsageLimit |
||
| + | Here is an example JLinkScript file that shows how to implement the RAM usage limitation for flash programming. |
||
| − | J-Link's "Unlimited flash breakpoints" works in both internal and external flash, even memory mapped QSPI flashes! |
||
| + | *[[Media:Template_SetRamUsageLimit.JLinkScript | Template_SetRamUsageLimit.JLinkScript]] |
||
| + | For more information about command strings in general and how to use them in various environments / IDEs, please refer to the J-Link User Guide (UM08001), chapter "Command strings" |
||
| − | |||
| − | |||
| − | |||
| − | |||
| − | J-Link OB is a single chip microcontroller "on-board" version of J-Link. It is designed to be a low-cost, single chip, on-board debug solution for evaluation boards. There are various J-Link-OB implementations available, which are based on different devices. This article refers to the J-Link-OB-RX621-ARM-SWD which is a J-Link-OB based on the Renesas RX621 series devices which is capable of debugging ARM based target devices like the Renesas Synergy series devices. For more information about what J-Link-OB, please refer to [https://www.segger.com/jlink-ob.html https://www.segger.com/jlink-ob.html] |
||
| − | |||
| − | == Enumeration under Ubuntu running in VirtualBox fails == |
||
| − | |||
| − | === Problem Description === |
||
| − | Under special circumstances and with a special setup, it could happen with older bootloader versions of the J-Link-OB-RX621-ARM-SWD, that enumerating via USB in a Ubuntu environment running in VirtualBox failed and J-Link was not detected properly under Ubuntu. SEGGER has reproduced the issue with the following setup but it may also occur under other constellations as well: |
||
| − | * Host OS: Win7 64-bit |
||
| − | * VirtualBox: Version 5.0.18 |
||
| − | * VirtualBox guest OS: Ubuntu 14.04 LTS |
||
| − | |||
| − | The problem only occurred if the J-Linkk was enumerating directly inside the VirtualBox guest OS. If it initially enumerated under the host OS and was connected to the VirtualBox guest OS later on, it worked fine. |
||
| − | |||
| − | === Affected Evaluation Boards === |
||
| − | This J-Link-OB model for example is used on the Renesas Synergy development kits. |
||
| − | |||
| − | === Replacing the Bootloader (Fix) === |
||
| − | As the fix requires to replace the bootloader of the J-Link OB, which can result (even if very unlikely) in a unusable J-Link-OB, the fix for this is not automatically applied when a new version of the J-Link software is installed. In the following it is described how to replace the bootloader of the J-Link-OB. |
||
| − | |||
| − | '''The following should only be done if you are affected by this problem. Please make sure that power supply to the J-Link-OB is stable. Unstable power supply during bootloader replacement can result in an unusable J-Link-OB.''' |
||
| − | |||
| − | Download and install J-Link software V5.41b or later: |
||
| − | * [https://www.segger.com/jlink-software-beta-version.html Betas] |
||
| − | * [https://www.segger.com/jlink-software.html Releases] |
||
| − | Start J-Link Commander and perform firmware update if asked for |
||
| − | |||
| − | Execute '''updatebtl''' command |
||
| − | SEGGER J-Link Commander V5.41b (Compiled May 3 2016 13:50:50) |
||
| − | DLL version V5.41b, compiled May 3 2016 13:50:27 |
||
| − | |||
| − | Connecting to J-Link via USB...O.K. |
||
| − | Firmware: J-Link OB RX621-ARM-SWD V1 compiled May 3 2016 12:18:23 |
||
| − | Hardware version: V2.10 |
||
| − | S/N: 708000000 |
||
| − | VTref = 3.300V |
||
| − | |||
| − | |||
| − | Type "connect" to establish a target connection, '?' for help |
||
| − | J-Link>updatebtl |
||
| − | O.K. |
||
| − | J-Link> |
||
Latest revision as of 15:10, 18 October 2021
By default, the number of breakpoints that can be set, when debugging in flash memory, is limited to the number of hardware breakpoints that are supported by the device. The number of hardware breakpoints being supported usually ranges from 2 (e.g. ARM7/9, Cortex-M0) to 6 (e.g. Cortex-M3/M4/M7). For devices where J-Link supports direct download into flash memory, it also supports setting an unlimited number of breakpoints when debugging in flash (further called unlimited flash breakpoints). For what devices flash download (and therefore also unlimited flash breakpoints) is supported, can be seen on our website: Device list. Unlimited flash breakpoints are available in different kinds of memory mapped flashes, be it internal flash, external parallel CFI flash or memory QSPI flash, as long as the flash supports direct execution of code (meaning it is read-accessible via the regular address space of the device).
Contents
How do Unlimited flash breakpoints work?
For more information about how the technique behind Unlimited flash breakpoints work, please refer to our website.
Precautions when using DMAs in the target application
As using unlimited flash breakpoints means that the flash is reprogrammed by J-Link, some RAM buffer is temporarily needed by J-Link, during the flash reprogramming process. The J-Link DLL makes sure that original RAM contents are preserved before the flash programming and restored afterwards.
Please note that DMAs are usually not halted while the CPU of the device is halted and continue operating which will interfere with the flash reprogramming process if a DMA uses the same RAM area as the flashloader of J-Link does. Usually the first 2-4 KiB of the internal RAM of a device are temporarily used by J-Link during flash reprogramming. Please make sure that this area is not used by DMAs in case unlimited flash breakpoints shall be used. As a target device usually provides many different DMAs and their presence/absence heavily depends on the specific device type (even for the same series, smaller/bigger models may implement more or less DMAs), it cannot be supported in a generic way to pause/temporarily disable all DMAs during flash reporgramming.
Limiting the temporary RAM buffer used for flash programming
The J-Link DLL allows to limit the max. RAM area that is used during flash programming. This can be achieved via different options which are explained in the following.
Setting the RAM limit impacts the performance of the flash programming speed. Setting the limit below 512 bytes is not recommended and may result in flash programming to not work.
Via Command String
The J-Link DLL allows to limit the max. RAM area that is used during flash programming, via the following command string:
SetRAMUsageLimit
Here is an example JLinkScript file that shows how to implement the RAM usage limitation for flash programming.
For more information about command strings in general and how to use them in various environments / IDEs, please refer to the J-Link User Guide (UM08001), chapter "Command strings"
