Alex Crawford [Thu, 16 Sep 2021 17:00:25 +0000 (10:00 -0700)]
driver/linuxgpiod: add support for opendrain srst
Some MCUs (e.g. the STM32F3) directly expose the internal reset line to
an external pin. When this signal is driven by a push/pull line, it can
actually be inhibited by the external driver. This results in a setup
where the MCU cannot reset itself, for example, by a watchdog timeout or
a sysreset request. To fix this condition, support for open drain output
on the SRST line is required.
Note that because `reset_config srst_open_drain` is the default, all
users of this adapter will switch over to an open drain output unless
explicitly configured otherwise.
Signed-off-by: Alex Crawford <openocd@code.acrawford.com>
Change-Id: I89b39b03aa03f826ed3c45793412780448940bcc
Reviewed-on: https://review.openocd.org/c/openocd/+/6559 Tested-by: jenkins Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tim Newsome [Thu, 2 Sep 2021 18:11:30 +0000 (11:11 -0700)]
Speed up remote bitbang.
1. Use TCP_NODELAY, which makes things twice as fast.
2. Get rid of a bunch of unnecessary socket block/non-block calls, which
improves speed another 10% or so.
Change-Id: I415db5746d55374a14564b1973b81e3517f5cb67 Signed-off-by: Tim Newsome <tim@sifive.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6534 Tested-by: jenkins Reviewed-by: Jan Matyas <matyas@codasip.com> Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Antonio Borneo [Fri, 17 Sep 2021 16:37:41 +0000 (18:37 +0200)]
openocd: prevent jimtcl error message while testing commands
The jimtcl API Jim_GetCommand() sets an error message when the
command is not found and flag JIM_ERRMSG is set.
OpenOCD is checking if the command has already been registered,
thus 'command not found' is the desired case.
Pass flag JIM_NONE to prevent jimtcl from setting the error
message.
Change-Id: I3329c2f8722eda0cc9a5f9cbd888a37915b46107 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6562 Tested-by: jenkins
Antonio Borneo [Fri, 17 Sep 2021 16:47:20 +0000 (18:47 +0200)]
arm_tpiu_swo: fix support for deprecated 'tpiu' command before 'init'
Commit dc7b32ea4a00 ("armv7m_trace: get rid of the old tpiu code")
is not handling correctly the old 'tpiu' command if it is run
during the config phase (before command 'init').
Move the call to the old event handler 'trace-config' in function
jim_arm_tpiu_swo_enable(), so it is correctly executed after
'init'.
Add the call to the old event handler 'trace-config' also during
jim_arm_tpiu_swo_disable(), to match the old behaviour.
Add more information while alerting that the event 'trace-config'
is deprecated.
Change-Id: If831d9159b4634c74e19c04099d041a6e2be3f2a Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Fixes: dc7b32ea4a00 ("armv7m_trace: get rid of the old tpiu code")
Reviewed-on: https://review.openocd.org/c/openocd/+/6561 Tested-by: jenkins Reviewed-by: Karl Palsson <karlp@tweak.net.au>
Antonio Borneo [Fri, 20 Aug 2021 22:35:32 +0000 (00:35 +0200)]
arm_adi_v5: drop ANY_ID from table dap_part_nums
The initial version of the table dap_part_nums contains only the
part number of the device and not the manufacturer ID.
This causes collisions between devices with same part number but
from different manufacturer.
The table has been extended to include the manufacturer JEDEC code
in commit 2f131d3c3004 ("ARM ADIv5: CoreSight ROM decode part
number and designer id").
For two old/legacy table's entries reported without manufacturer
code it was defined a special ANY_ID manufacturer, meaning skip
the check for manufacturer!
The two legacy entries report the comment "from OMAP3 memmap", and
thanks to the associated string has been possible through Google
to identify a Master Report [1] about using OpenOCD with the OMAP3
in a BeagleBoard. The ROM table is printed with OpenOCD command
"dap info 1" at page 8 and reports the Peripheral ID required to
extract the manufacturer ID that, out of any surprise, belong to
Texas Instruments.
Set the two missing manufacturer ID to Texas Instruments JEDEC
code.
Remove the now redundant definition and use of ANY_ID.
While revisiting this old code, remove also the useless comment
"0x113: what?". It was introduced in commit ddade10d4a93 ("ARM
ADIv5: "dap info" gets more readable") and from the same dump in
[1] it's clearly another element in OMAP3. It is listed as entry
0x8 in the ROM table and there is no further info available.
OpenOCD will anyway list it as:
Designer is 0x017, Texas Instruments
Part is 0x113, Unrecognized
Another link https://elinux.org/BeagleBoardOpenOCD reports the
text "Part number 0x113: This is ????", which sounds familiar!
No public document from Texas Instruments reports what is this
device at address 0x54012000.
[1] Warren Clay Grant - University of Texas at Austin
"Implementation of an Open Source JTAG Debugging Development
Chain for the BeagleBoard ARMĀ® Cortex A-8" - May 2012 Link: https://repositories.lib.utexas.edu/bitstream/handle/2152/ETD-UT-2012-05-5478/GRANT-MASTERS-REPORT.pdf
Change-Id: I7e007addbb5c6e90303e4e8c110c7d27810fbe9c Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6454 Tested-by: jenkins Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Antonio Borneo [Tue, 10 Aug 2021 16:09:28 +0000 (18:09 +0200)]
arm_adi_v5: simplify handling of AP type
The complete AP type should include 'class' and 'manufacturer'.
Cleanup the definition of AP type from AP_REG_IDR register.
Include the check of 'class', together with manufacturer and type.
Add the new MEM-AP from ARM IHI0074C.
Change-Id: Ic8db7c040108ba237b54f73b1abe24b8b853699b Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6447 Tested-by: jenkins Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com> Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Antonio Borneo [Mon, 16 Aug 2021 17:08:23 +0000 (19:08 +0200)]
armv7m.h: relax dependency from 'arm_adi_v5.h'
The include file 'armv7m.h' includes 'arm_adi_v5.h' only to get
the definition of 'struct adiv5_ap', but doesn't need the struct
content.
Reducing the cross dependencies speeds-up the compile time during
code development by avoiding re-compiling file.
Relax the dependency by locally declaring 'struct adiv5_ap' in
'armv7m.h' and remove the include of 'arm_adi_v5.h'.
Fix the other files that have now lost the includes file that
'arm_adi_v5.h' depends from.
Change-Id: Ic0d40b17db6045fa43f348bda83eaf211a6b347d Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6468 Tested-by: jenkins Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com> Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Tarek BOCHKATI [Wed, 11 Aug 2021 00:14:21 +0000 (01:14 +0100)]
helper/command: fix echo return values
the echo command is managed through command handler and not jim_handler
to be consistent rename the handler from jim_echo to handle_echo
and update the return values
We are already at the limit for the number of VID/PID pairs declared
in stlink.cfg and stlink-dap.cfg. Increase the maximum number of pairs
from 8 to 16 to make room for a few more devices.
Signed-off-by: Andreas Sandberg <andreas@sandberg.uk>
Change-Id: Ifad8e7ef67b930edbb5421730f00eb3390812f06
Reviewed-on: https://review.openocd.org/c/openocd/+/6554 Tested-by: jenkins Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com> Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
flash/stm32l4x: fix flash programming in 64-bit hosts
stm32l4_work_area struct is shared between the loader and stm32l4x flash driver
'*wp' and '*rp' pointers' size is 4 bytes each since stm32l4x devices have
32-bit processors.
however when used in openocd code, their size depends on the host
if the host is 32-bit, then the size is 4 bytes each.
if the host is 64-bit, then the size is 8 bytes each.
to avoid this size difference, change their types depending on the
usage (pointers for the loader, and 32-bit integers in openocd code).
Change-Id: I0a3df4bb4bf872b01cdb9357eb28307868d7d469 Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6556 Tested-by: jenkins Reviewed-by: Yestin Sun <sunyi0804@gmail.com> Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Tarek BOCHKATI [Sun, 29 Aug 2021 15:33:55 +0000 (16:33 +0100)]
flash/stm32l4x: fix segmentation fault with HLA adapters and STM32WLx devices
CPU2 (Cortex-M0+) is supported only with non-hla adapters because it is on AP1.
Using HLA adapters armv7m.debug_ap is null, and checking ap_num triggers
a segfault.
flash/nor/tcl: fix the flash name returned by 'flash list' command
The 'flash list' command returns the driver name as flash name which seems
to be incorrect, the proposal is:
- to fix this by returning the flash name
- and add a new item 'driver' in the returned list
example:
before the change
> flash list
{name stm32l4x base 134217728 size 0 bus_width 0 chip_width 0}
{name stm32l4x base 201326592 size 0 bus_width 0 chip_width 0}
{name stm32l4x base 200933376 size 0 bus_width 0 chip_width 0}
after the change
> flash list
{name stm32l5x.flash_ns driver stm32l4x ...}
{name stm32l5x.flash_alias_s driver stm32l4x ...}
{name stm32l5x.otp driver stm32l4x ...}
This version of jimtcl:
- fixes memory leak in API Jim_CreateCommand();
- fixes 'make distcheck';
- uses single-argument syntax for 'expr'.
With the 'expr' syntax already fixed in all the tcl scripts in
OpenOCD, let's use the latest jimtcl to check it and anticipate
any further issues.
By using this version, the workaround for the memory leak and for
distcheck can be reverted.
Antonio Borneo [Sun, 29 Aug 2021 23:01:40 +0000 (01:01 +0200)]
openocd: prepare for jimtcl 0.81 'expr' syntax change
Jimtcl commit 1843b79a03dd ("expr: TIP 526, only support a single
arg") drops the support for multi-argument syntax for the TCL
command 'expr'.
All the scripts distributed with OpenOCD are already compliant
with the new syntax.
To avoid breaking user script, introduce a replacement for 'expr'
command that handles the old syntax while issuing a deprecated
warning.
This change should be part of OpenOCD v0.12.0, then reverted.
Tarek BOCHKATI [Fri, 26 Mar 2021 14:07:41 +0000 (15:07 +0100)]
flash/stm32l4x: add support of STM32WB1x
STM32WB1x devices has a single flash bank up to 320 KB (page 2KB)
note: STM32WB5x/WB3x are single banks as well but do have 4KB as page size.
note: remove the assert that checks if max_mages is power of two, because
STM32WB1x flash size is not a power of 2
Tarek BOCHKATI [Sat, 6 Mar 2021 21:46:35 +0000 (22:46 +0100)]
flash/stm32l4x: switch to to c loader instead of assembly loader
switching to C loader instead of the assembly version will enhance readability
will reduce the maintenance effort.
besides the switch to C loader, we added a new parameters to the loader
like flash_word_size and flash_sr_bsy_mask in order to support properly
STM32U5x and STM32G0Bx/G0Cx in dual-bank mode.
Tarek BOCHKATI [Tue, 17 Aug 2021 12:29:56 +0000 (13:29 +0100)]
server/telnet: support 'CTRL+C'
like in terminal 'CTRL+C':
- keeps the line content so the user can refer to it (like copy/paste)
- marks the line with '^C', as hint that the command was not executed
- permit the user to write a new command
Antonio Borneo [Sat, 15 May 2021 21:14:18 +0000 (23:14 +0200)]
Makefile: drop warning suppression on win build
Commit dcdf71c21b99 ("- fix signed/unsigned build errors under
win32. Thanks Zach Welch <zw@superlucidity.net>") in 2009 prevents
gcc warnings on sign/unsigned comparisons while building for Win
on folders 'helper' and 'server'.
In 2011, commit b69119668ed8 ("RTOS Thread awareness support wip")
uses the same method on the new folder 'rtos'.
In mean time, all the incorrect sign/unsigned comparisons has been
fixed and no warning is present with the default -Wextra flag that
implies -Wsign-compare.
The comment:
# FD_* macros are sloppy with their signs on MinGW32 platform
seems linked to some old implementation of MinGW32 include file
that doesn't apply on current versions.
Remove the obsolete hacks to suppress the warnings.
Antonio Borneo [Sat, 15 May 2021 22:48:49 +0000 (00:48 +0200)]
helper: remove fix for libusb pre-v1.0.9
Libusb v1.0.9 has been released on April 2012. We can reasonably
expect that every user has already updated his system to a libusb
newer of equel to v1.0.9.
Tarek BOCHKATI [Tue, 16 Mar 2021 15:10:59 +0000 (16:10 +0100)]
flash/stm32l4x: add support of STM32U57x/U58x
this device flash registers are quite similar to STM32L5
with this changes :
- flash size is up to 2MB
- 2MB variants are always dual bank
- 1MB and 512KB variants could be dual bank (contiguous addressing)
depending on DUALBANK bit(21)
- flash data width is 16 bytes (quad-word)
Tarek BOCHKATI [Thu, 4 Feb 2021 21:43:52 +0000 (22:43 +0100)]
flash/stm32l4x: add support of STM32WL5x dual core
according the RM0453, the second core have a different Flash CR and SR
registers for flash operations (called C2CR and C2SR).
so we need to a different flash_regs than older L4 devices.
@see stm32wl_cpu2_flash_regs
the C2CR register don't contain LOCK and OPTLOCK bits, and this explain
the addition of new register index called STM32_FLASH_CR_WLK_INDEX to
look-up the CR with lock, to be used in locking/unlocking the flash.
note: DBGMCU_IDCODE cannot be read using CPU1 (Cortex-M0+) at AP1,
to solve this read the UID64 (IEEE 64-bit unique device ID register)
flash/stm32l4x: prevent undefined behavior warnings caused by signed integer operations
When running OpenOCD with -fsanitize=undefined, a warning is emitted
for an bit-shifting operation whose result cannot be stored in a
signed integer.
This is because (1 << 31) overflows a signed integer, which is
undefined behavior. By making each of the bit masks act on an
unsigned number, the warning is avoided.
Whether this warning emitted by UBSan would ever manifest into a real
error is debatable, but fixing this does make UBSan happy.
Tarek BOCHKATI [Tue, 19 Jan 2021 12:26:48 +0000 (13:26 +0100)]
flash/stm32l4x: add support of STM32G0Bx/G0Cx devices
this device has a dual bank flash architecture up to 512 KB (page 2KB)
reference: RM0444 Rev 5
notes:
- 128k variant is always single bank
- 256k variant flash is contiguous (no gap) in dual bank mode
- BKER is bit 13 vs bit 11 for other devices
> added cr_bker_mask in stm32l4_flash_bank struct
- BSY2 for bank 2 operations
> added sr_bsy_mask in stm32l4_flash_bank struct
> proposed optimization: always wait for (BSY1 | BSY2) with
STM32G0Bx/G0Cx devices only (for L4+ devices BSY2=PEMPTY)
TODO: update flashloader to use the proper BSY bits
temporarily don't use the loader in dual bank mode
This struct element is replaced by the usage of F_HAS_L5_FLASH_REGS flag:
since over this driver stm32l4_flash_regs is the default register layout,
and the only exception is STM32L5 family,
so it's simpler to manage it using a flag.
Note: the same flag will be used with STM32U5 devices, as they have
the same registers layout, which explains the move of stm32l5_s_flash_regs
before the switch(device_id) in order to not re-write this for STM32U5.
Tarek BOCHKATI [Fri, 22 Jan 2021 12:15:52 +0000 (13:15 +0100)]
flash/stm32l4x: STM32L5 support programming when TZEN=1 and RDP=0x55
when RDP level is 0.5 the provided work-area should reside in non-secure RAM
to ensure that:
- add a hint in the driver level
- reduce the usage of secure RAM only when TZEN=1 and RDP is not 0.5
(check the target configuration file)
flash/stm32l4x: do not report bank mode before probing [FIX]
in line 1391, get_stm32l4_bank_type_str(bank) will always output the same
value "Flash single" since the variable stm32l4_info->dual_bank_mode is false
by default, stm32l4_info->dual_bank_mode will be set correctly afterward
in the switch case at line 1467
thus the need to remove the usage of get_stm32l4_bank_type_str(bank) before
stm32l4_info->dual_bank_mode initialization.
Fixes: 64c2e03b23d9 ("flash/nor: improved API of flash_driver.info & fixed buffer overruns")
Change-Id: Ia8dc7e144e0ded6143682eb514c247f27859ff81 Signed-off-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6411 Reviewed-by: Oleksij Rempel <linux@rempel-privat.de> Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com> Tested-by: jenkins
root [Thu, 3 Jun 2021 09:37:37 +0000 (11:37 +0200)]
target/adi_v5_jtag: Add support for 8-bit IR JTAG-DP
As per Arm Debug Interface Architecture Specification (ADIv5.0 to
ADIv5.2), B3.3.1, the JTAG-DP as an IR length of 4 or 8 bits
depending on the ARM implementation. The current code
only support 4-bit and this patch extends the support to 8-bit IR.
Not tested back yet on a 4-bit target.
Change-Id: Ie4f875dc336caf014c6cfced57574b54d0970623 Signed-off-by: Antoine C. <acalando@free.fr>
Reviewed-on: https://review.openocd.org/c/openocd/+/6285 Tested-by: jenkins Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Antonio Borneo [Sun, 8 Aug 2021 11:51:33 +0000 (13:51 +0200)]
jep106: use packed jedec manufacturer code
JEP106 encodes JEDEC-assigned manufacture code as:
a) a sequence of zero or more escape codes 0x7f;
b) an odd-parity bit of the next 7 bits;
c) 7 bits.
The same code is often represented as a single value composed by
the logical OR between:
- the number of escape codes in a), shifted left by 7 positions;
- the 7 bits in c).
This is the preferred packed representation used by this change.
Currently there are only two uses of JEP106 in openocd to get the
manufacturer name:
- to decode the JTAG IDCODE of each TAP, where the JEP106 code is
already packed as in the preferred representation above in bits
IDCODE[11:1];
- to decode the ARM CoreSight PIDR register, where the JEP106 code
is split in 3 parts:
= PIDR3[3:0], corresponding to bits [10:7] of the packed code;
= PIDR2[2:0], corresponding to bits [6:4] of the packed code;
= PIDR1[7:4], corresponding to bits [3:0] of the packed code.
Wrap the existing JEP106 decode function in a simpler API using
the packed code.
Simplify the callers by skipping the bit unpacking.
Change the manufacturer code in CoreSight table dap_partnums[] to
match the packed representation, by removing the always-one bit 7
erroneously taken from PIDR bit JEDEC and included in the former
table.
Change-Id: I63eb4da9e6801fab25e330f1f6b792d2fd619493 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6418 Tested-by: jenkins
Antonio Borneo [Wed, 11 Aug 2021 15:03:18 +0000 (17:03 +0200)]
arm_adi_v5: update coresight class names
Update the list of ARM coresight classes wrt to latest ARM
documentation.
Use c99 array designator to easily track changes in future.
Add a comment for the entry "OptimoDE DESS". It was added in 2009
by David Brownell, but Google cannot find any reference other than
this line in openocd code its associated commit. It should not be
an issue keeping it as is.
Change-Id: Ia3b646131ee68ca5263095c3a0aeaf75c004b324 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6431 Tested-by: jenkins
Antonio Borneo [Wed, 11 Aug 2021 22:14:29 +0000 (00:14 +0200)]
command: log the command only when it is executed
In case of multi-word commands, the command dispatcher is nested
called at each word during command name parsing.
The improper position of the call to script_debug() causes the
command line to be logged once at each parsed word.
In the example of command "cpu arm disassemble 0" the full command
is logged three times for "cpu", "arm" and "disassemble":
Debug: 656617 61843 command.c:201 script_debug(): command - cpu arm disassemble 0
Debug: 656618 61843 command.c:201 script_debug(): command - cpu arm disassemble 0
Debug: 656619 61843 command.c:201 script_debug(): command - cpu arm disassemble 0
Call script_debug() only when the parsing is terminated and the
command handler is going to be executed.
Antonio Borneo [Fri, 13 Aug 2021 16:52:20 +0000 (18:52 +0200)]
cortex_m: fix command 'step address'
The command 'step' accepts an optional parameter 'address' to run
the step-by-step execution from an address different from current
program counter.
When OpenOCD sets the new program counter value in the register
cache, it doesn't flag it as dirty. The following call to function
armv7m_restore_context() does not propagate the new value of the
program counter to the target. This cause the target to continue
from the old program counter value, ignoring the user's request.
It is hard to notice the issue if the target is halted in an idle
loop! In fact the default mode to operate step-by-step is to set a
breakpoint to the following instruction and resume execution. In
the idle loop the CPU will pass through the breakpoint whatever
the resume address is. User will find the target halting at the
instruction following 'address' which is consistent with the
expected behaviour of command 'step address'.
To verify the issue on an STM32F4, use a dummy code in SRAM:
halt
mww 0x20000000 0xbf00bf00
mww 0x20000004 0xbf00bf00
mww 0x20000008 0xe7fcbf00
arm disassemble 0x20000000 6
0x20000000 bf00 nop
0x20000002 bf00 nop
0x20000004 bf00 nop
+--> 0x20000006 bf00 nop
| 0x20000008 bf00 nop
+-<- 0x2000000a e7fc b #0x20000006
resume 0x20000006
halt
step 0x20000000
the target doesn't halt because it is in the loop from 0x20000006
to 0x2000000a. The 'step 0x20000000' did not changed the program
counter so the temporary breakpoint at 0x20000002 is never hit.
Then:
halt
step 0x20000008
target halted ...
... pc: 0x2000000a
gives the feeling that only the instruction at 0x20000008 has been
executed, but actually the whole loop has been executed from the
place 'halt' stopped the execution till the breakpoint at the
instruction following 0x20000008.
Flag the program counter cached value as 'valid' and 'dirty' to
force armv7m_restore_context() to update the target's register.
Change-Id: I49bd8bb95b2f5429ec38ed016f2ad706618ae68a Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6434 Tested-by: jenkins Reviewed-by: Tomas Vanek <vanekt@fbl.cz>
Antonio Borneo [Thu, 19 Aug 2021 14:07:21 +0000 (16:07 +0200)]
stlink: fix SWIM mode on stlink-v3
Commit 89f07325f2e7 ("stlink: Set speed before entering JTAG/SWD
mode") anticipates setting the adapter speed just before entering
in the JTAG/SWD mode. This to initiate the communication with the
speed selected by the user.
But SWIM doesn't allow setting the speed before entering in SWIM
mode. The resulting error causes OpenOCD to quit.
The problem only happens with stlink-v3, due to the different way
to set the adapter speed on different stlink versions.
Set the speed before entering in the mode only for JTAG and SWD
modes.
Change-Id: Iab42cd9d72ecfac14c7e17bae74e0dee2218b235 Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com> Fixes: 89f07325f2e7 ("stlink: Set speed before entering JTAG/SWD mode")
Reviewed-on: https://review.openocd.org/c/openocd/+/6443 Tested-by: jenkins Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
rtos/riot: fix out-of-bounds writes when target is corrupted
This protects against out-of-bounds writes when the memory
of RIOT's scheduler is corrupted.
This memory can be corrupted because of:
- Programming errors
- The scheduler not yet having been initialised
- An incorrect symbol file being used during debugging.
This error can result in OpenOCD segfaulting. Valgrind was
used to find the approximate location of the error.
Change-Id: I60e7d7c245b8c4e38f4c98cb0c0347a9b5ec3177 Signed-off-by: Sebastiaan de Schaetzen <sebastiaan.de.schaetzen@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6381 Tested-by: jenkins Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>