Programming and debugging

[julkas]

Most of the stuff is already available on github, check

https://github.com/michael-ring/mbf/tree/master/Patches

@MiR thanks. Good work.

but I found out that for people the learning curve for embedded is a little too steep as you have to compile trunk and apply several patches for all the supported platforms, unfortunately not that much works out of the box, especially when it comes to debugging.

Why trunk?

That's why I am now trying to put all the stuff inside of fpcupdeluxe.

I don't know fpcupdeluxe.

[MiR]

Why Trunk:

Christo has done a lot of great work to make avr target work well, afaik this is only available on trunk,  support for mipsel (Pic32mx) is also only on  Trunk.

You can use release version of fpc for arm development but the number of supported microcontrollers is a little limited.

And for Lazarus, there are fixes done by Martin Frb that allow easier use of the gdbserver and the number of pre-alocated breakpoints can be reduced which helps for avr chips and for cortex-m0 which only have support for one or two real hardware breakpoints. I have not checked if those features are already in release versions of lazarus, but they are quite new developments so most likely they are not.

[julkas]

Off topic. Who is Christo?

[ccrause]

Off topic. Who is Christo?

The answer should be revealed by the context of the reply in message 333090...

[julkas]

Off topic. Who is Christo?

The answer should be revealed by the context of the reply in message 333090...

https://en.m.wikipedia.org/wiki/Christos_(given_name)

[MiR]

@Avra:

Were you able to make your installation work?

[avra]

I checked your fpc.cfg and saw some lines at the end that show me that you tried to build the Embedded Target of fpcupdeluxe.

You are right. Somehow I completely forgotten I did that and even didn't think it mattered at the time. I was wrong and apologize for the inconvenience.

take the fpc.cfg file attached here, it works for your installation directory

First I used your file without changes (after rebuild all) and then for the first time IDE didn't complain during compilation but it didn't let me run the BluePill blinky code. It said "Unable to run c:\fpcupdeluxe-embedded\mbf\SamplesBoa...\Blinky". Then I examined your fpc.cfg file and saw that it has mixed C:\Prg\Lazarus\stm32x64\ and C:\fpcupdeluxe-embedded\ paths. Since this time I used C:\fpcupdeluxe-embedded\ for fpcupdeluxe I adapted all paths to that. You can find that new config file attached. Then I tried both yours and mine config files, but I get either a mentioned error or Lazarus hangs immediately after F9 and I had to kill it.

Before every try I could connect and disconnect with ST32CubeProgrammer (btw. much later I tried to use it to download produced hex file to BluePill and run it. Led was not blinking).

Yesterday I had so many tries and failures that I had enough for the day and switched off the plug.

Today I wanted to try something fresh, and try to locate PlatformIO st-util, since I knew programming and debugging works well with PlatformIO, and it was the same GDB server we tried working with Lazarus. At first try I could finally debug and execute step by step. Hoooray! Unfortunately there is one issue, but I will cover that separately in the next post.

If after cleanup/rebuild and using my fpc.cfg it still does not work for you then please send me the complete buildlog vith -va option enabled, I can then compare with the installation I did on my computer.

If you still think this is needed then please say so in which exact configuration and I will do it.

Btw. Note for anyone trying to locate PlatformIO GDB server executable, on my pc it is located here:
c:\Users\avra\.platformio\packages\tool-stm32duino\texane-stlink\st-util.exe
I have archived whole dir and attached. Yes, attachment holds executables, so if anyone is suspicious then don't download it and use one from PlatformIO.

EDIT: I have just checked and with PlatformIO st-util both my new c:\fpcupdeluxe-embedded and old c:\PRG\Lazarus\stm32x64 debugging partly work, showing the same issue explained in the next message.

[avra]

Here are the screenshots of the debugging issue I have now. When stepping over line 33:

Code: Pascal  [Select][+][-]

1. SystemCore.Delay(500);

assembler window with some error is automatically shown.

If I continue debugging I get

Debugger encountered and error when trying to run/step the application
...
,msg="Cannot find bounds of current function"

[avra]

Strange. When I try to F7 into Delay(), debugger enters the method, but after 2-3 seconds st-utils exits and I get the debugger error message.

[avra]

I have also tried to delete all other break points and put just one in first statement of Delay method, and result is the same.

[MiR]

I can reproduce your issue, funny thing is that this issue only shows when you Debug into SystemCore.
When you Debug into GPIO then things work as expected.

I will have to check if the same happens with JLink to see if this is GDBServer related or something else.
The probe disconnects when trying to read the stack of a method from within Systemcore. Has most likely nothing to do with breakpoints.

But one omportant Note on Breakpoints:

With st-util (and also with original st software) you only have 6 Hardware Breakpoints and you quickly run out of those. So make sure that you do set only the absolute minimum of breakpoints.

You can disable some of the automagically set Breakpoints by Lazarus, this gives a little more Breating room.

Anyway, I am glad that your system is up and running, sorry that the fpc.cfg was mixed up, I created a fresh instance with your directory and expected it to have only paths related to your environment. But that's a story for another day.

Michael

[MiR]

Can you please add

-godwarfcpp

to custom Project options?

I played arround a lot on both windows and mac and with this option things work better (but not perfect)

Debugging is quite OK when you put a breakpoint in the routine you stepped into, this fixes some crazyness for step over command.

[avra]

Debugging is quite OK when you put a breakpoint in the routine you stepped into, this fixes some crazyness for step over command.

I can confirm that -godwarfcpp allows to step into Delay method and step over inside of it. However after some step overs when I try to run the code I get the same error. I also still get the same error if I try to step over Delay method (line 33), or if I simply put break on line 34 and try to run the code. Something inside of Delay method triggers the error.

I can look into some J-Link clone if you think that would work better. Or I might try to convert my BluePill or ST-Link into Black Magic Probe.

[MiR]

I guess the problem is in Lazarus/fpc, with JLink the situation is exactly the same.

please do not buy JLink Clones, the originals from Edu line are quite cheap and not limited in any way, it is imho not worth the risk of buying a clone.

Upgrading your st-link to Black Magic Probe is a good idea in the future, but lazarus is not yet ready for this.
You need to connect in a slightly different way and then you need to send commands to the device, this currently does only work as a hack. But a solution may be on the  Horizon. So for now i‘d propose to stay with the st firmware

Michael

[avra]

I guess the problem is in Lazarus/fpc, with JLink the situation is exactly the same.

Then I do not need J-Link.

Upgrading your st-link to Black Magic Probe is a good idea in the future, but lazarus is not yet ready for this.

Thanks for telling me. I didn't know that.

I have enabled "Reset debugger after each run" and put "c:\Users\avra\.platformio\packages\tool-stm32duino\texane-stlink\st-util.exe" into InitExec_RemoteTarget. Now GDB server is automatically started before each debug session, and it is automatically closed on the end so I do not have to fire it manually. Also there is no freezing no matter how many times I start and stop debugging or exit on error, but sporadically from time to time I get some access violation in Lazarus debug session that I can safely ignore (at least I see no negative effect).