[davidoz]

Yes, I can see your update.  I’ll add a comment that the issue hasn’t been resolved yet. That might get their attention.  It sounds like the fault is on the Microsoft side, so does that mean the call stack works with the latest VisualGDB (v5.5R4) but an older Visual Studio (say VS2015)?

The workaround I’ve been using is when the call stack disappears, I single step one assembler instruction and then it repopulates the call stack window.

Cheers

David

[davidoz]

Hi Support,

looks like Microsoft closed your report a while ago, but no resolution.  I know it’s not a show stopper, but it is really annoying.  Is there any chance you could get Microsoft to re-open the issue?

 

Cheers

David

 

[davidoz]

Hi Support,

Thanks for your reply.  I’m on VS 16.8.3 and I have upgraded VisualGDB to 5.5R4.  Unfortunately, the issue is still occurring.  Please let me know if you want me to do anything.

Cheers

David

[davidoz]

The DHCSR register returns 0x00000000 when read (i.e. C_DEBUGEN is 0).  Strangely the memory window shows the register address contains 0x00030003, but when I assign it to a variable it contains 0x00000000.

I can write a custom CanInvokeSemihostingCalls(), but I don’t have anyway of checking if the debugger is attached either.

I have seen in a forum the cortex-m0 does not have access to the DHCSR register, but I can’t find any documentation that supports that.  Assuming that is true, they say a BKPT instruction will cause a hard fault to occur if no debugger is attached.  That can be used to determine if it’s attached.  That does mean you will get a breakpoint every time if the debugger is attached.  Doesn’t sound worth the trouble.

 

Cheers

David

 

[davidoz]

Hi Support, sorry for late reply.

When j-link debugger is attached and if “Ignore Semihosting If No Debugger is Attached” is selected, then CanInvokeSemihostingCalls() always returns FALSE.  i.e. the register @ 0xE000EDF0 contains 0x00000000.

It’s strange because the debugger works – setting breakpoints, single stepping, etc, so it knows it is connected.

 

Cheers

David

 

• This reply was modified 3 years, 6 months ago by davidoz.

[davidoz]

Hi, I forgot I had this question outstanding.  I believe we’re all paid up again, so do you have any suggestions on how to fix the issue?

Cheers

David

[davidoz]

Wow, has it been a year already.  I’ll let you know when the payment is authorised.

[davidoz]

Sorry, the tables aren’t working, but it’s suffice to say when the “When running without a debugger”  setting is “Ignore profiling/semihosting calls” and a J-Link is attached then no semihosting messages are received.

 

 

[davidoz]

Hi,

This issue gave me a lot grief too.  It’s actually a defect in the Hal.  I logged a bug report quite a while ago, but I haven’t heard anything about a fix.  It happens when it de-initialises the clock, the macro changes some reserved bits in the register.  You can view the bug here:

https://github.com/STMicroelectronics/STM32CubeH7/issues/19

So my workaround is in stm32h7xx_hal_rcc.h:

change

#define __HAL_RCC_AHB3_FORCE_RESET() (RCC->AHB3RSTR = 0xFFFFFFFFU)

with this

#define __HAL_RCC_AHB3_RESET_ALL (RCC_AHB3RSTR_MDMARST | \
                                  RCC_AHB3RSTR_DMA2DRST | \
                                  RCC_AHB3RSTR_JPGDECRST | \
                                  RCC_AHB3RSTR_FMCRST | \
                                  RCC_AHB3RSTR_QSPIRST | \
                                  RCC_AHB3RSTR_SDMMC1RST)
#define __HAL_RCC_AHB3_FORCE_RESET() (RCC->AHB3RSTR = __HAL_RCC_AHB3_RESET_ALL)

[davidoz]

Hi Support,

Yes, the new build works.  Thank you for the quick resolution of this issue.  The support from Sysprogs has been great.

Cheers

David

 

[davidoz]

Hi Support,

I think it’s close to working.  I copied the new DLL to the host computer and remote computer (just in case).  I also modified the settings file to this:

<PreferredTelnetPort>4444</PreferredTelnetPort>
<TelnetHostName>10.10.243.100</TelnetHostName>

So I launch OpenOCD on the remote computer manually like this:

com.sysprogs.arm.openocd\bin\openocd.exe -c "bindto 0.0.0.0" -c "gdb_port 65085" -c "telnet_port 4444" -f interface/stlink.cfg -f target/stm32f0x.cfg -c init -c "reset init" -c "echo VisualGDB_OpenOCD_Ready"

It outputs this:

VisualGDB_OpenOCD_Ready
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

I then start the debugger on the host computer.  It downloads the firmware to the micro on the remote computer, and then starts running the firmware.  A dialog appears saying the debug method doesn’t work with semihosting.  I click ok and the firmware continues.  It does not attempt to make the telnet connection (confirmed by wireshark).

I can start a telnet connection manually on the host computer and it connects to the remote computer on port 4444.  However, I don’t see any of my semihosting messages.  I send this command through the telnet:

arm semihosting enable

It confirms semihosting is enabled, but still no messages.

I’ve traced the firmware.  I see _write() call your <span>WriteToFastSemihostingChannel()</span> function, but after that I lose it in the assembler.

VisualGDB still launches a local OpenOCD even though GDB is talking to the one running on remote computer.  I don’t know if that has anything to do with semihosting not working.

 

Cheers

David

 

• This reply was modified 4 years ago by davidoz.

[davidoz]

Don’t worry Support.  I found where the DLL goes.  Thanks.

[davidoz]

Hi Support.  Thanks for your advice.  I’ve downloaded the file.  On my machine it has an extension of *.dll.  Is it really a DLL and if so where does it go?  I know we’ve had an issue with your server (or the internet) changing the extension of files in the past.  I’ve tried renaming the extension other things, but nothing worked.

Cheers

David

[davidoz]

The file extension issue is a known peculiarity with IE/Edge.  Something about the network not identifying the file type correctly so IE renames it to *.man.

There’s a fix for the server side if you’re interested.  It doesn’t bother me though.  Renaming the file is easy enough.

https://answers.microsoft.com/en-us/ie/forum/all/downloading-an-msi-file-renames-it-man-really/590868e5-d0a4-4815-99b9-667a097340a3

 

Cheers

David

 

[davidoz]

Wow, that was quick.  I can now turn off  the ‘bin’ file generation for external memories.  I like the new build window too.

Cheers

David

p/s I think the extension on the build file is incorrect.  It downloaded a .man file instead of .msi.

[Author]

Posts