> Do you have a link?
This perhaps?
https://community.st.com/t5/stm32-mcu-products/stm32f746-cortex-m7-silicon-bug-singlestep-lands-in-interrupt/m-p/357481
> On 11 Aug 2023, at 15:56, James Murray wrote:
>
> I believe that this has been discussed on ST's forum.
Do you have a link?
> Some core
> revisions have this bug and ST's response is that it will not be fixed.
> OpenOCD already prints an alert on connection for buggy cores.
>
> STM32F745
> > On 7 Aug 2023, at 10:45, Tomas Vanek
> > wrote:
> >
> > The problem with a debug break induced into an interrupt handler is
> > same as we observed
> > in other Cortex-M7 versions.
>
> ok, so probably all STM Cortex-M7 cores are affected.
>
> did you inform someone at STM/Arm?
>
> > Curre
> On 7 Aug 2023, at 10:45, Tomas Vanek wrote:
>
> The problem with a debug break induced into an interrupt handler is same as
> we observed
> in other Cortex-M7 versions.
ok, so probably all STM Cortex-M7 cores are affected.
did you inform someone at STM/Arm?
> Currently I don't have enou
On 17/07/2023 00:25, Liviu Ionescu wrote:
On 17 Jul 2023, at 00:18, Tomas Vanek wrote:
Such breakpoint would collide with the induced rogue break - don't place any
breakpoint to the PendSV_Handler(), just watch `pendsv_cnt` when execution
stops at BKPT instruction.
...
We need to make sure
On 20/07/2023 09:50, Tomas Vanek wrote:
On 19/07/2023 22:14, Liviu Ionescu wrote:
On 17 Jul 2023, at 09:13, Tomas Vanek
wrote:
Andreas sent me a hint:
On 15/07/2023 11:44, Andreas Bolsch wrote:
According to AN4891, table 7, STM32H72x/3x are r1p2, but RM0468
doesn't mention r/p for the CPU
A few days ago I tried to send this message, but apparently it was not
forwarded by the server.
I'm resending it, with the attachment replaced by a link to Dropbox:
-
https://www.dropbox.com/scl/fi/25jhwbrlfe9zykyodaslg/f767-tests-debug.zip?rlkey=1lwv6nd6r5pwy0fj4mxqtpgkt&dl=0
Liviu
> On 21
> Don't be so naive.
Thanks for taking the suggestion in the spirit that it was made. :-/
On 22/07/2023 00:22, Tommy Murphy wrote:
> I might be wrong, but as far as I can tell, the ST-Link GDB server
does not implement semihosting.
I presumed that Tomas was referring to the earlier minimal
self-contained test that didn't use semihosting?
No, I meant the OS based unit test with se
On 22/07/2023 00:11, Liviu Ionescu wrote:
On 21 Jul 2023, at 20:36, Tomas Vanek wrote:
Could you try the test under ST-Link GDB server?
I might be wrong, but as far as I can tell, the ST-Link GDB server does not
implement semihosting.
Liviu
Didn't know that. No point in doing so then.
> I might be wrong, but as far as I can tell, the ST-Link GDB server does not
> implement semihosting.
I presumed that Tomas was referring to the earlier minimal self-contained test
that didn't use semihosting?
This whole thread is getting a bit confusing in my opinion.
Why not run the minimal
> On 21 Jul 2023, at 20:36, Tomas Vanek wrote:
>
> Could you try the test under ST-Link GDB server?
I might be wrong, but as far as I can tell, the ST-Link GDB server does not
implement semihosting.
Liviu
> Can this be implemented in OpenOCD?
Was it clearly ascertained earlier that this cannot be done via a Tcl script
debug-halted (or similar - I think that there was another handler that was more
relevant but I can't seem to find it in the user manual?) event handler? That
would be preferable to
> On 21 Jul 2023, at 19:02, Tomas Vanek wrote:
>
> But later comparisons of OpenOCD runs of my simple test code with J-Link and
> ST-link GDB servers suggested that J-link and ST-link GDB servers keep
> interrupts masked.
> Your last test shows it's not as easy as that, they implement some f
> On 21 Jul 2023, at 19:02, Tomas Vanek wrote:
>
>> Can you provide more details on what "cortex_m maskisr on" does? How long
>> are the interrupts masked?
>
> Is it so difficult to search it in the manual?
Command: cortex_m maskisr (auto|on|off|steponly)
Control masking (disabling) interru
On 21/07/2023 18:14, Liviu Ionescu wrote:
On 21 Jul 2023, at 19:02, Tomas Vanek wrote:
Does this test code run under ST-link GDB server?
It runs in a debug session in Eclipse with J-Link.
Liviu
I asked specifically for ST-Link GDB server because I'm able to test it.
I don't have a J-Link
> But later comparisons of OpenOCD runs of my simple
test code with J-Link and ST-link GDB servers suggested that J-link and ST-link
GDB servers keep interrupts masked.
> Your last test shows it's not as easy as that, they implement some fiddling
> with C_MASKINTS. Perhaps they unmask interrupts
> On 21 Jul 2023, at 19:02, Tomas Vanek wrote:
>
> Does this test code run under ST-link GDB server?
It runs in a debug session in Eclipse with J-Link.
Liviu
On 21/07/2023 16:33, Liviu Ionescu wrote:
On 21 Jul 2023, at 16:55, Tomas Vanek wrote:
You have to use "interface/stlink-dap.cfg" as I wrote, not
"interface/stlink.cfg"
oops!
It went a bit further, but it hang when trying to start the scheduler:
```
1: Test command: /Users/ilg/Work/xpack-
> On 21 Jul 2023, at 17:09, Sergey A. Borshch
> wrote:
>
> Try to insert "-c" "init" before this command.
The command was not recognised by "interface/stlink.cfg".
I changed to "interface/stlink-dap.cfg", execution started, but hang when
trying to start the scheduler.
1: Test command:
/Us
On 21.07.2023 16:36, Liviu Ionescu wrote:
I have no idea why the command is not recognised.
If you have suggestions for further tests, please be sure you pass the full
openocd command to use, since I do not know the correct order of command line
options.
Try to insert "-c" "init" before this
> On 20 Jul 2023, at 10:50, Tomas Vanek wrote:
>
> So 'cortex_m maskisr on' didn't work and interrupts was not masked.
>
> Try:
>
> openocd "-c" "gdb_port disabled" "-c" "tcl_port disabled" "-c" "telnet_port
> disabled" "-f" "interface/stlink-dap.cfg" "-f" "target/stm32f7x.cfg"
> "-c" "prog
> I rechecked the command and run a similar one myself.
> You probably missed the message
> "target must be stopped for "maskisr" command"
> and cut it out from the mailed part of the log as well.
This is why attaching a full and unmodified `openocd -d3` verbose log is so
important when investiga
On 19/07/2023 22:14, Liviu Ionescu wrote:
On 17 Jul 2023, at 09:13, Tomas Vanek
wrote:
Andreas sent me a hint:
On 15/07/2023 11:44, Andreas Bolsch wrote:
According to AN4891, table 7, STM32H72x/3x are r1p2, but RM0468
doesn't mention r/p for the CPU.
I'll ask ST for one...
Any estimated t
> On 17 Jul 2023, at 09:13, Tomas Vanek wrote:
>
> Andreas sent me a hint:
>
> On 15/07/2023 11:44, Andreas Bolsch wrote:
>> According to AN4891, table 7, STM32H72x/3x are r1p2, but RM0468 doesn't
>> mention r/p for the CPU.
>
> I'll ask ST for one...
Any estimated time when we'll know if
Hi Liviu
I'm a bit confused by this:
> With the OpenOCD that comes within CubeIDE, 'maskisr on' prevents the PendSV
> to fire, execution stops only on the BRK and pendsv_cnt remains 0.
>
> With 'maskisr auto' the behaviour is the initial one, each run has a rogue
> break and pendsv_cnt increase
> On 17 Jul 2023, at 18:41, Tommy Murphy wrote:
>
> I assumed that all OpenOCD tests were being done with your own xPack OpenOCD.
> Are you saying that this is not the case or that you are testing with xPack
> OpenOCD *and* this CubeIDE OpenOCD?
The initial report was based on the runs of th
On 17/07/2023 07:28, Liviu Ionescu wrote:
On 15 Jul 2023, at 12:09, Tomas Vanek wrote:
I'm more interested in testing the newest r1p2. Any tip to a device containing
Cortex-M7 r1p2 core?
Any owner of r1p2 device keen to run the test?
The H743 board that I have also reports r1p1, and the H74
> On 17 Jul 2023, at 01:40, Tommy Murphy wrote:
>
> Does OpenOCD with `cortex_m maskisr on` (or `auto`?) give the same results? I
> know that you tried it before but in a different test scenario so maybe it's
> worth trying again with the simplified test?
With the OpenOCD that comes within
> On 15 Jul 2023, at 12:09, Tomas Vanek wrote:
>
> I'm more interested in testing the newest r1p2. Any tip to a device
> containing Cortex-M7 r1p2 core?
> Any owner of r1p2 device keen to run the test?
The H743 board that I have also reports r1p1, and the H745 I can get in a few
days is pre
> With J-Link and ST-LINK GDB server, the counter does not go past 1, so it
> looks like the debuggers indeed mask interrupts
Does OpenOCD with `cortex_m maskisr on` (or `auto`?) give the same results? I
know that you tried it before but in a different test scenario so maybe it's
worth trying a
> On 17 Jul 2023, at 00:18, Tomas Vanek wrote:
>
> Such breakpoint would collide with the induced rogue break - don't place any
> breakpoint to the PendSV_Handler(), just watch `pendsv_cnt` when execution
> stops at BKPT instruction.
...
> We need to make sure the PendSV_Handler() is called b
On 16/07/2023 21:52, Liviu Ionescu wrote:
On 16 Jul 2023, at 22:13, Tomas Vanek wrote:
Just to be sure, check the counter with J-Link and ST-LINK GDB server
I placed a breakpoint on the `pendsv_cnt++;` in the PendSV_Handler, and an
Expression watch in Eclipse on the `pendsv_cnt` variable.
S
> On 16 Jul 2023, at 22:13, Tomas Vanek wrote:
>
> Just to be sure, check the counter with J-Link and ST-LINK GDB server
I placed a breakpoint on the `pendsv_cnt++;` in the PendSV_Handler, and an
Expression watch in Eclipse on the `pendsv_cnt` variable.
With both the J-Link and the ST-LINK
On 16/07/2023 20:49, Liviu Ionescu wrote:
On 16 Jul 2023, at 21:37, Tomas Vanek wrote:
The counter has a good reason: it's an easy way to check if PendSV_Handler() is
really called
and the debugger does not mask interrupts.
I see. In my test I did not check the value of this counter, I assu
> On 16 Jul 2023, at 21:37, Tomas Vanek wrote:
>
> The counter has a good reason: it's an easy way to check if PendSV_Handler()
> is really called
> and the debugger does not mask interrupts.
I see. In my test I did not check the value of this counter, I assumed that if
the debugger halted
On 16/07/2023 19:37, Liviu Ionescu wrote:
I added the pendsv_cnt counter in the PendSV_Handler(), but I think this is not
very relevant to the test.
The counter has a good reason: it's an easy way to check if
PendSV_Handler() is really called
and the debugger does not mask interrupts.
> On 14 Jul 2023, at 20:31, Tommy Murphy wrote:
>
> presumably something that Liviu might try on his target?
The target was the NUCLEO-F767ZI, connected via two probes, the on-board
ST/LINK-v2 with the latest firmware, and a J-Link EDU Mini, connected via the
6-pin SWD connecter, patched to
Thanks for checking Tomas.
Perhaps the issue is not related to the dual issue nature of the CPU after all.
Any Arm or STM people reading who might want to chip in perhaps? ;-)
On 15/07/2023 13:13, Tommy Murphy wrote:
Thanks Tomas.
I wonder if playing with ACTLR[20:16] aka DISDI has any impact on this
test? I don't think that dual issue can be completely disabled in case
it's a factor here? Maybe set it to 0x3F and see if that makes any
difference?
https://develop
> Maybe set it to 0x3F and see if that makes any difference?
Sorry, 0x1F. :-)
Thanks Tomas.
I wonder if playing with ACTLR[20:16] aka DISDI has any impact on this test? I
don't think that dual issue can be completely disabled in case it's a factor
here? Maybe set it to 0x3F and see if that makes any difference?
https://developer.arm.com/documentation/dui0646/a/Cortex-M7-
On 14/07/2023 19:31, Tommy Murphy wrote:
> The code reliably replicating the issue on STM32F767
Hi Tomas - that's very interesting and presumably something that Liviu
might try on his target? Can you clarify the rXpY version of your
target please? Thanks.
So far tested:
STM32F767 nucleo boar
> On 14 Jul 2023, at 20:31, Tommy Murphy wrote:
>
> presumably something that Liviu might try on his target?
tomorrow I'll not be at my computer, I'll try to do it the day after tomorrow.
and I'll also compare with SEGGER J-Link.
Liviu
> The code reliably replicating the issue on STM32F767
Hi Tomas - that's very interesting and presumably something that Liviu might
try on his target? Can you clarify the rXpY version of your target please?
Thanks.
On Fri, Jul 14, 2023 at 6:53 PM Tomas Vanek
wrote:
>
> On 14/07/2023 00:30, Tomas Vanek wrote:
>
>
> Unfortunately (if I'm not completely wrong guessing the mechanism of the
> errata) each rogue break also means that
> one semihosting operation gets skipped. So your test will keep running, time
On 14/07/2023 00:30, Tomas Vanek wrote:
Unfortunately (if I'm not completely wrong guessing the mechanism of
the errata) each rogue break also means that
one semihosting operation gets skipped. So your test will keep
running, time to time some semihosted output get lost.
T
Not really! The s
> Not 'debug-halted' but 'halted' (the 'debug-halted' event is issued at the
> end of a target algo, we have to fix the doc)
If breakpoints can be ignored/resumed automatically using this event handler
mechanism then, in my opinion, this arguably renders moot the suggestion of
adding a flag and
> On 14 Jul 2023, at 01:30, Tomas Vanek wrote:
>
> ... it takes at least 30 milliseconds
> on average adapter and Cortex-M - all that time the core is in debug halt and
> interrupts cannot be serviced.
I see. That's a lot, but, at least for my unit tests, it is not a problem.
FYI, SEGGER J-
On 13/07/2023 23:06, Liviu Ionescu wrote:
On 13 Jul 2023, at 23:48, Tommy Murphy wrote:
I presume that the breakpoints used to implement semihosting (e.g. 0xBEAB for Cortex-M7)
do actually cause the target to go into debug halt for a period of time even if they're
subsequently automatically
> and I thought that perhaps OpenOCD can do it. Was I too optimistic?
To be fair, there is no clear evidence so far that the problem that you're
hitting here - with the SysTick handler stopping as if there was a breakpoint -
is the fault of OpenOCD and not, perhaps, a bug in the target Cortex-M7
> On 13 Jul 2023, at 23:48, Tommy Murphy wrote:
>
> I presume that the breakpoints used to implement semihosting (e.g. 0xBEAB for
> Cortex-M7) do actually cause the target to go into debug halt for a period of
> time even if they're subsequently automatically resumed as part of the
> semiho
>> BTW combining semihosting with interrupts is not a good practice anyway.
>> Except some basic tests the interrupts are unusable due
>> to giant latencies caused by debug halts.
> Hmmm... Can you be more specific on this? What halts do you mean? I
> definitely do not set any breakpoints in my
> On 13 Jul 2023, at 23:17, Michael Schwingen wrote:
>
> I would propose to add a switch to ignore breakpoints and automatically resume
Yes, this is a possible solution.
However I would like to clarify if OpenOCD is able to run in standalone
semihosting mode, in order to conveniently run un
On 13.07.23 20:30, Liviu Ionescu wrote:
On 13 Jul 2023, at 19:12, Liviu Ionescu wrote:
... change OpenOCD to resume it when running with semihosting enabled but
standalone (i.e. not in a debug session).
Question: what do you think should be a correct behaviour for OpenOCD when an
explicit
> On 13 Jul 2023, at 22:46, Tommy Murphy wrote:
>
> Even if all ports (GDB, Tcl, telnet) are disabled (and there is no pipe
> connection from GDB?) and the only commands used are passed from the OpenOCD
> command line directly or via scripts? Wouldn't that be a sort of "standalone"
> mode?
> On 13 Jul 2023, at 22:09, Tomas Vanek wrote:
>
> It should *NOT* resume. The main purpose of a breakpoint is to stop the
> execution.
Actually "to stop the execution **during a debug session**".
> Connecting OpenOCD to a target implies enabling the debug mode of the device
> so IMO there
> so IMO there is nothing like "standalone" mode.
Even if all ports (GDB, Tcl, telnet) are disabled (and there is no pipe
connection from GDB?) and the only commands used are passed from the OpenOCD
command line directly or via scripts? Wouldn't that be a sort of "standalone"
mode?
On 13/07/2023 20:30, Liviu Ionescu wrote:
On 13 Jul 2023, at 19:12, Liviu Ionescu wrote:
... change OpenOCD to resume it when running with semihosting enabled but
standalone (i.e. not in a debug session).
Question: what do you think should be a correct behaviour for OpenOCD when an
explici
> On 13 Jul 2023, at 19:12, Liviu Ionescu wrote:
>
> ... change OpenOCD to resume it when running with semihosting enabled but
> standalone (i.e. not in a debug session).
Question: what do you think should be a correct behaviour for OpenOCD when an
explicit BKPT 0 (regular breakpoint) is en
I did some more tests, and exactly the same code runs just fine on Rapsberry
RP2040, STM NUCLEO-F411 and a board with STM32H743.
On STM32F767 the issue occurred in 2 of the 3 tests, in different locations at
different moments in time, differently on slow (RPI4) and fast (MacMini).
A simple loop
> On 11 Jul 2023, at 22:46, Antonio Borneo wrote:
>
> Instead of putchar ('.'), use close(0)
I tried a forever loop with:
```
call_host(SEMIHOSTING_SYS_ERRNO, NULL);
```
I left it running for tens of minutes and... not a single halt :-(
it's getting frustrating...
Liviu
> On 11 Jul 2023, at 13:21, Antonio Borneo wrote:
>
> It could be interesting to test with
> -c 'init;cortex_m maskisr on'
> on the command line.
I used the following:
1: Test command:
/Users/ilg/Work/xpack-dev-tools-build/openocd-0.12.0-2/darwin-x64/application/bin/openocd
"-c" "gdb_port
Sorry for being quiet for a while, I asked my friends for help and now I also
have a board with a STM32H743, I'll try it later.
> On 11 Jul 2023, at 10:11, Tomas Vanek wrote:
>
> It is a problem in the ARM licensed silicon so it may or more likely may not
> be described in ST device errata.
>
> Couldn't it be related to the MASKINTS erratum of Cortex-M7 r0p1 ...
Liviu - can you clarify the revision of your target Cortex-M7?
If it's not r0p2 or later then presumably this erratum does not apply?
> It could be interesting to test with -c 'init;cortex_m maskisr on'
And if that does elimi
> Do you know how to check if there was a HW breakpoint set? I guess there are
> some registers in the debug logic which store these addresses. can we dump
> these registers?
The FP_COMPn registers?
https://developer.arm.com/documentation/ddi0489/f/debug/about-the-fpb/fpb-programmers-model
The
I was ignoring the errata, as it's titled "single stepping", which is
not Liviu's case.
But reading it carefully, under "Conditions" that can trigger the
issue there is "The processor exits Debug state."
So we could assume that at the resume from a semihosting BKPT, a
SysTick interrupt is pending a
On 11/07/2023 09:11, Tomas Vanek wrote:
I'm not familiar with the details of semihosting implementation, I
assume that the semihosting BKPT must be
overcome by single step like any other BKPT.
I was wrong with my assumption: single stepping is used to skip over SW
breakpoints inserted in debug
On 11/07/2023 08:13, Liviu Ionescu wrote:
On 11 Jul 2023, at 08:44, Tomas Vanek wrote:
Couldn't it be related to the MASKINTS erratum of Cortex-M7 r0p1 ...
I checked the 'STM32F76xxx/77xxx device errata', ES0334 - Rev 9 - December
2022, but could not find anything related.
Liviu
It is a
> On 11 Jul 2023, at 08:44, Tomas Vanek wrote:
>
> Couldn't it be related to the MASKINTS erratum of Cortex-M7 r0p1 ...
I checked the 'STM32F76xxx/77xxx device errata', ES0334 - Rev 9 - December
2022, but could not find anything related.
Liviu
Liviu, Antonio,
On 11/07/2023 07:22, Liviu Ionescu wrote:
On 11 Jul 2023, at 00:50, Antonio Borneo wrote:
From what you say, it's not a matter of adapter (CMSIS-DAP and STLINK
give the same issue). It's not HLA vs Cortex-M.
That's correct
But you only get it on Cortex-M7, correct?
I can o
> On 11 Jul 2023, at 00:50, Antonio Borneo wrote:
>
> Indeed, the behavior is weird. And as far as I know, this is the first
> time it is reported.
>
> Note: you have instrumented mem_ap_read_u32() with a LOG_INFO(), but
> the printed content of "value" is not updated yet.
> In fact mem_ap_re
Indeed, the behavior is weird. And as far as I know, this is the first
time it is reported.
Note: you have instrumented mem_ap_read_u32() with a LOG_INFO(), but
the printed content of "value" is not updated yet.
In fact mem_ap_read_u32() queues the read, but you are printing the
uninitialized valu
> On 10 Jul 2023, at 21:37, Antonio Borneo wrote:
>
> the log:
>> 1: Info : adapter_poll
>> 1: Info : stlink_usb_v2_read_debug_reg 0xE000EDF0 0x01030003
> reports that, while reading register DHCSR, OpenOCD found that the CPU
> is halted. Then it expects it is due to a breakpoint.
>
> Are you
Hi Liviu,
the log:
> 1: Info : adapter_poll
> 1: Info : stlink_usb_v2_read_debug_reg 0xE000EDF0 0x01030003
reports that, while reading register DHCSR, OpenOCD found that the CPU
is halted. Then it expects it is due to a breakpoint.
Are you sure there is not any pending HW breakpoint?
The address
75 matches
Mail list logo
