Semihosting is not working after 1.5.1 with STM32F429 #1038

jiayihu · 2020-09-23T21:40:11Z

Thank you for giving feedback to the stlink project.

NOTICE: Please read and follow instructions in #906 before submitting a ticket. This feature request will be deleted without notice when not enough information is provided! So please ensure that all fields are filled out.

I made serious effort to avoid creating duplicate or nearly similar issue

In order to allow developers and other contributors to isolate and target your respective issue, please take some time to fill out each of the following items appropriate to your specific problem:

Programmer/board type: stlink-v2
Operating system and version: MacOS
Stlink tools version and/or git commit hash: 1.6.1 via brew
Stlink commandline tool name: st-util --semihosting
Target chip (and board if applicable): STM32F429I-DISC

Futher we kindly ask you to describe the detected problem as detailed as possible and to add debug output if available, by using the following template:

Commandline-Output:

2020-09-23T23:35:30 INFO common.c: F42x/F43x: 256 KiB SRAM, 2048 KiB flash in at least 16 KiB pages.
2020-09-23T23:35:30 INFO gdb-server.c: Listening at *:4242...
2020-09-23T23:35:33 INFO gdb-server.c: Found 6 hw breakpoint registers
2020-09-23T23:35:33 INFO gdb-server.c: GDB connected.
2020-09-23T23:35:33 INFO common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134217728 (0x8000000)
EraseFlash - Sector:0x0 Size:0x4000 2020-09-23T23:35:33 INFO common.c: Flash page at addr: 0x08000000 erased
2020-09-23T23:35:33 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-09-23T23:35:33 INFO common.c: Starting Flash write for F2/F4/L4
2020-09-23T23:35:33 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 16384
2020-09-23T23:35:34 INFO common.c: Starting verification of write complete
2020-09-23T23:35:34 INFO common.c: Flash written and verified! jolly good!
2020-09-23T23:35:34 INFO common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134234112 (0x8004000)
EraseFlash - Sector:0x1 Size:0x4000 2020-09-23T23:35:34 INFO common.c: Flash page at addr: 0x08004000 erased
2020-09-23T23:35:34 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-09-23T23:35:34 INFO common.c: Starting Flash write for F2/F4/L4
2020-09-23T23:35:34 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 16384
2020-09-23T23:35:34 INFO common.c: Starting verification of write complete
2020-09-23T23:35:34 INFO common.c: Flash written and verified! jolly good!
2020-09-23T23:35:34 INFO common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134250496 (0x8008000)
EraseFlash - Sector:0x2 Size:0x4000 2020-09-23T23:35:35 INFO common.c: Flash page at addr: 0x08008000 erased
2020-09-23T23:35:35 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-09-23T23:35:35 INFO common.c: Starting Flash write for F2/F4/L4
2020-09-23T23:35:35 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 16384
2020-09-23T23:35:35 INFO common.c: Starting verification of write complete
2020-09-23T23:35:35 INFO common.c: Flash written and verified! jolly good!
2020-09-23T23:35:35 INFO common.c: Attempting to write 16384 (0x4000) bytes to stm32 address: 134266880 (0x800c000)
EraseFlash - Sector:0x3 Size:0x4000 2020-09-23T23:35:35 INFO common.c: Flash page at addr: 0x0800c000 erased
2020-09-23T23:35:35 INFO common.c: Finished erasing 1 pages of 16384 (0x4000) bytes
2020-09-23T23:35:35 INFO common.c: Starting Flash write for F2/F4/L4
2020-09-23T23:35:35 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 16384
2020-09-23T23:35:36 INFO common.c: Starting verification of write complete
2020-09-23T23:35:36 INFO common.c: Flash written and verified! jolly good!
2020-09-23T23:35:36 INFO common.c: Attempting to write 65536 (0x10000) bytes to stm32 address: 134283264 (0x8010000)
EraseFlash - Sector:0x4 Size:0x10000 2020-09-23T23:35:36 INFO common.c: Flash page at addr: 0x08010000 erased
2020-09-23T23:35:36 INFO common.c: Finished erasing 1 pages of 65536 (0x10000) bytes
2020-09-23T23:35:36 INFO common.c: Starting Flash write for F2/F4/L4
2020-09-23T23:35:36 INFO flash_loader.c: Successfully loaded flash loader in sram
enabling 32-bit flash writes
size: 32768
size: 32768
2020-09-23T23:35:37 INFO common.c: Starting verification of write complete
2020-09-23T23:35:38 INFO common.c: Flash written and verified! jolly good!

Expected/description:

I have been debugging today using semihosting but it was not working despite using an application which I was sure it was fine some months ago. Then I tried to compile version 1.5.1 which I was using and st-util --semihosting works there, whereas with the new versions results in SIGTRAP

Thank you for your support.

The stlink project maintainers

The text was updated successfully, but these errors were encountered:

Ant-ON · 2020-10-25T10:38:41Z

I think it regression is fixed by #1027.
@jiayihu May you try latest develop branch?

Nightwalker-87 · 2020-12-29T19:42:49Z

@jiayihu to be more precisely: Please test commit ba5c679 and the previous commit 5c03678 to verify this.

jiayihu · 2021-01-04T15:21:03Z

Sorry guys, I'm not using semihosting anymore so I can't test it against master for the time being. Maybe someone else can do it, there was a deleted comment by someone else some days ago having the same issue.

Nightwalker-87 · 2021-03-09T21:50:20Z

@Ant-ON Can you or anybody else test instead?
I have never used this feature, so I'm not sure if I can give any useful assessment here.

Nightwalker-87 · 2021-04-03T18:13:06Z

@jiayihu Even though you don't use --semihosting any more: Can you please provide the commands you executed in gdb and tell us more about the actual issue to be able to have it investigated? This ticket is now open and thus should not be closed without a solution.

jiayihu · 2021-04-03T19:36:03Z

I didn't use gdb, I just ran st-util --semihosting. Btw, if nobody else can test the fix just give me some time. I'm writing my master thesis right now, but after the deadline on the 15th of this month, I'll try to find a moment to test it on my board

Nightwalker-87 · 2021-04-03T19:49:00Z

@jiayihu: Thx for coming back to this. Note that st-util --semihosting alone does not do anything apart from opening a debug server listening and waiting for interaction with a gdb debugger. (As far as I am aware of.) Also check our tutorial (/doc/tutorial.md) on this.
I believe it is important to understand the behaviour you expected in contrast to the actual implementation. Maybe there was some confusion, please let us know. Shall there be any need for further testing later on, after the 15th should be fine - we'll see.

jiayihu · 2021-04-03T20:05:11Z

Oh you're right, I went back to my workflow and I used this .gdbinit

file "./obj/gee"

target extended-remote :4242

load
break main

continue

And ran with arm-none-eabi-gdb

Nightwalker-87 · 2021-04-03T20:11:08Z

Ok, thanks - I'll try this out with my Bluepill board and possibly with a borrowed Nucleo STM32F429ZI (if functional... 😕).

Nightwalker-87 · 2021-04-03T22:00:22Z

Here is my output when trying to reproduce your command sequence on develop (HEAD) with a Bluepill (CKS32F103C8T6):

$ gdb-multiarch
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

(gdb) target extended-remote :4242
Remote debugging using :4242
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
0x00000000 in ?? ()
(gdb) file /[...]/Blinker/Release/Blinker.elf
A program is being debugged already.
Are you sure you want to change the file? (y or n) y
Reading symbols from /[...]/Blinker/Release/Blinker.elf...
(No debugging symbols found in /[...]/Blinker/Release/Blinker.elf)
(gdb) load
Loading section .isr_vector, size 0x130 lma 0x8000000
Loading section .text, size 0xbac lma 0x8000130
Loading section .rodata, size 0x74 lma 0x8000cdc
Loading section .init_array, size 0x4 lma 0x8000d50
Loading section .fini_array, size 0x4 lma 0x8000d54
Loading section .data, size 0x68 lma 0x8000d58
Start address 0x080002b4, load size 3520
Transfer rate: 13 KB/sec, 586 bytes/write.
(gdb) break main
Breakpoint 1 at 0x8000234
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) continue
Continuing.

Breakpoint 1, 0x08000234 in main ()
(gdb)

... which looks good to me and is what to expect AFAIK.

Nightwalker-87 · 2021-04-03T22:35:40Z

Here is my output when trying to reproduce your command sequence on develop (HEAD) with a Nucleo STM32F429ZI:

$ gdb-multiarch
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

(gdb) file /home/nightwalker-87/Schreibtisch/Blinker/Release/Blinker.elf
Reading symbols from /home/nightwalker-87/Schreibtisch/Blinker/Release/Blinker.elf...
(No debugging symbols found in /home/nightwalker-87/Schreibtisch/Blinker/Release/Blinker.elf)
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
0x08000234 in main ()
(gdb) load
Loading section .isr_vector, size 0x130 lma 0x8000000
Loading section .text, size 0xbac lma 0x8000130
Loading section .rodata, size 0x74 lma 0x8000cdc
Loading section .init_array, size 0x4 lma 0x8000d50
Loading section .fini_array, size 0x4 lma 0x8000d54
Loading section .data, size 0x68 lma 0x8000d58

... and nothing else happened in gdb while receiving continuous output of

[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE
[!] send_recv STLINK_JTAG_READDEBUG_32BIT
[!] send_recv send request failed: LIBUSB_ERROR_NO_DEVICE

on the gdb-server (st-util --semihosting) side.

This led me to the approach to update the firmware of the STLINK/V2-1 on-board programmer to V2.J37.M27.

This leads to:

$ gdb-multiarch
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

(gdb) file /[...]/Blinker/Release/Blinker.elf
Reading symbols from /[...]/Blinker/Release/Blinker.elf...
(No debugging symbols found in /[...]/Blinker/Release/Blinker.elf)
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
0x00000000 in ?? ()
(gdb) load
Loading section .isr_vector, size 0x130 lma 0x8000000
Loading section .text, size 0xbac lma 0x8000130
Loading section .rodata, size 0x74 lma 0x8000cdc
Loading section .init_array, size 0x4 lma 0x8000d50
Loading section .fini_array, size 0x4 lma 0x8000d54
Loading section .data, size 0x68 lma 0x8000d58
Start address 0x080002b4, load size 3520
Transfer rate: 5 KB/sec, 586 bytes/write.
(gdb) break main
Breakpoint 1 at 0x8000234
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) continue
Continuing.

Breakpoint 1, 0x08000234 in main ()
(gdb)

... which again looks good to me and is what to expect AFAIK.

Nightwalker-87 · 2021-04-03T22:40:46Z

What I can still do is to verify the observed results with v1.6.0 and v1.6.1 in order to find out about any possible inconsistencies in the codebase between v1.5.1 and v1.6.1.

Nightwalker-87 · 2021-04-04T22:08:04Z

Here is my output when trying to reproduce your command sequence for v1.6.1 with a Bluepill (CKS32F103C8T6):

$ gdb-multiarch
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

(gdb) file /[...]/Blinker/Release/Blinker.elf
Reading symbols from /[...]/Blinker/Release/Blinker.elf...
(No debugging symbols found in /[...]/Blinker/Release/Blinker.elf)
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
0x08000bb4 in _write_r ()
(gdb) load
Loading section .isr_vector, size 0x130 lma 0x8000000
Loading section .text, size 0xbac lma 0x8000130
Loading section .rodata, size 0x74 lma 0x8000cdc
Loading section .init_array, size 0x4 lma 0x8000d50
Loading section .fini_array, size 0x4 lma 0x8000d54
Loading section .data, size 0x68 lma 0x8000d58
Start address 0x080002b4, load size 3520
Transfer rate: 15 KB/sec, 586 bytes/write.
(gdb) break main
Breakpoint 1 at 0x8000234
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) continue
Continuing. <-- runs through previously set breakpoint, instead of halting...
^C <-- Abort with CTRL+C, to interrupt endless loop...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000bb4 in _write_r ()
(gdb)

... which does not work as expected.

Nightwalker-87 · 2021-04-04T22:20:31Z

Here is my output when trying to reproduce your command sequence for v1.6.1 with a Nucleo STM32F429ZI:

$ gdb-multiarch
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git

(gdb) file /[...]/Blinker/Release/Blinker.elf
Reading symbols from /[...]/Blinker/Release/Blinker.elf...
(No debugging symbols found in /[...]/Blinker/Release/Blinker.elf)
(gdb) target extended-remote localhost:4242
Remote debugging using localhost:4242
0x00000000 in ?? ()
(gdb) load
Loading section .isr_vector, size 0x130 lma 0x8000000
Loading section .text, size 0xbac lma 0x8000130
Loading section .rodata, size 0x74 lma 0x8000cdc
Loading section .init_array, size 0x4 lma 0x8000d50
Loading section .fini_array, size 0x4 lma 0x8000d54
Loading section .data, size 0x68 lma 0x8000d58
Start address 0x080002b4, load size 3520
Transfer rate: 5 KB/sec, 586 bytes/write.
(gdb) break main
Breakpoint 1 at 0x8000234
Note: automatically using hardware breakpoints for read-only addresses.
(gdb) continue
Continuing. <-- runs through previously set breakpoint, instead of halting...
^C <-- abort with CTRL+C, to interrupt endless loop...
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000bb4 in _write_r ()
(gdb)

... which also does not work as expected.

Nightwalker-87 · 2021-04-04T22:42:45Z

... so from my findings I believe to be able to verify that st-util --semihosting (still) does not work correctly in v1.6.1, but on current develop.

@Ant-ON; I'm no sure though if #1027 is the actual fix for this... Can you help to find and link the correct patch?

Ant-ON · 2021-04-05T04:00:04Z

@Nightwalker-87 Yes, this bug is related to #1027. Semihost uses the stlink_read_all_regs for determine a state:

stlink/src/st-util/gdb-server.c

Lines 1458 to 1469 in fe526ec

    
           ret = stlink_read_all_regs (sl, &reg); 
        
           if (ret) { DLOG("Semihost: read_all_regs failed\n"); } 
        
           // read PC 
        
           pc = reg.r[15]; 
        
           // compute aligned value 
        
           offset = pc % 4; 
        
           addr = pc - offset; 
        
           // read instructions (address and length must be aligned).

Nightwalker-87 · 2021-04-05T11:12:18Z

Fixed in #1027.

Nightwalker-87 added bug/needs-fix bug/regression labels Sep 23, 2020

Nightwalker-87 added this to the v1.6.2 milestone Sep 23, 2020

Nightwalker-87 added needs/investigation component/st-util os/macOS programmer/STLINK/V2 V2 / V2-A / V2-B target/stm32f4 labels Sep 23, 2020

Nightwalker-87 changed the title ~~[STM32F429]: Semihosting is not working after 1.5.1~~ Semihosting is not working after 1.5.1 with STM32F429 Sep 26, 2020

Nightwalker-87 mentioned this issue Mar 9, 2021

st-flash run_flash_loader(0x08000000) failed #356

Closed

Nightwalker-87 self-assigned this Apr 3, 2021

Nightwalker-87 added bug/fixed and removed bug/needs-fix labels Apr 4, 2021

Nightwalker-87 linked a pull request Apr 5, 2021 that will close this issue

Fixed reg_offset handling in stlink_usb_read_all_regs( ) #1027

Merged

Nightwalker-87 mentioned this issue Apr 5, 2021

Fixed reg_offset handling in stlink_usb_read_all_regs( ) #1027

Merged

Nightwalker-87 assigned Ant-ON Apr 5, 2021

Nightwalker-87 added status/resolved and removed needs/investigation labels Apr 5, 2021

Nightwalker-87 closed this as completed Apr 5, 2021

stlink-org locked as resolved and limited conversation to collaborators Apr 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Semihosting is not working after 1.5.1 with STM32F429 #1038

Semihosting is not working after 1.5.1 with STM32F429 #1038

jiayihu commented Sep 23, 2020

Ant-ON commented Oct 25, 2020

Nightwalker-87 commented Dec 29, 2020

jiayihu commented Jan 4, 2021 •

edited

Loading

Nightwalker-87 commented Mar 9, 2021

Nightwalker-87 commented Apr 3, 2021

jiayihu commented Apr 3, 2021

Nightwalker-87 commented Apr 3, 2021 •

edited

Loading

jiayihu commented Apr 3, 2021

Nightwalker-87 commented Apr 3, 2021

Nightwalker-87 commented Apr 3, 2021 •

edited

Loading

Nightwalker-87 commented Apr 3, 2021 •

edited

Loading

Nightwalker-87 commented Apr 3, 2021

Nightwalker-87 commented Apr 4, 2021 •

edited

Loading

Nightwalker-87 commented Apr 4, 2021 •

edited

Loading

Nightwalker-87 commented Apr 4, 2021 •

edited

Loading

Ant-ON commented Apr 5, 2021

Nightwalker-87 commented Apr 5, 2021

Semihosting is not working after 1.5.1 with STM32F429 #1038

Semihosting is not working after 1.5.1 with STM32F429 #1038

Comments

jiayihu commented Sep 23, 2020

Ant-ON commented Oct 25, 2020

Nightwalker-87 commented Dec 29, 2020

jiayihu commented Jan 4, 2021 • edited Loading

Nightwalker-87 commented Mar 9, 2021

Nightwalker-87 commented Apr 3, 2021

jiayihu commented Apr 3, 2021

Nightwalker-87 commented Apr 3, 2021 • edited Loading

jiayihu commented Apr 3, 2021

Nightwalker-87 commented Apr 3, 2021

Nightwalker-87 commented Apr 3, 2021 • edited Loading

Nightwalker-87 commented Apr 3, 2021 • edited Loading

Nightwalker-87 commented Apr 3, 2021

Nightwalker-87 commented Apr 4, 2021 • edited Loading

Nightwalker-87 commented Apr 4, 2021 • edited Loading

Nightwalker-87 commented Apr 4, 2021 • edited Loading

Ant-ON commented Apr 5, 2021

Nightwalker-87 commented Apr 5, 2021

jiayihu commented Jan 4, 2021 •

edited

Loading

Nightwalker-87 commented Apr 3, 2021 •

edited

Loading

Nightwalker-87 commented Apr 3, 2021 •

edited

Loading

Nightwalker-87 commented Apr 3, 2021 •

edited

Loading

Nightwalker-87 commented Apr 4, 2021 •

edited

Loading

Nightwalker-87 commented Apr 4, 2021 •

edited

Loading

Nightwalker-87 commented Apr 4, 2021 •

edited

Loading