Programming and debugging

[SymbolicFrank]

Where do I add a post-build step to program the chip, and what do I need to do to debug it? First in Windows, as I think that will be easiest.

The most common debugging is SWD and both steps normally use an ST-Link v2 programmer. I do have a command-line utility that can do both (help attached). But no idea how to integrate that into Lazarus. (Googling wasn't helpful.)

[ccrause]

One way of running tools/scripts is to specify the command in Project Options -> Compiler Options -> Compiler commands.  You can also use Lazarus macro's to pass e.g. the current project name to a script.

For debugging, can you connect to the ST-Link with gdb? If so, you can select the gdbserver option in Lazarus (Tools -> Options -> Debugger -> General then select GNU remote debugger and select the path+name of gdb for your target).  Hope this helps, I haven't worked with ARM targets before.  Note that the gdbserver option in Lazarus has a Debugger_Remote_DownloadExe option which can be used to program the controller, if supported by the rest of your tool chain.

There are definitely more experienced people around, hopefully they can give you more guidance.

[MiR]

When you talk about STLink v2 do you mean original stlink v2 / a nucleo/discovery board or a cheap china stlink clone?

I am asking because when you have a non clone product then you can go to www.segger.com and download a free upgrade of the debugger to segger´s JLink product:

https://www.segger.com/products/debug-probes/j-link/models/other-j-links/st-link-on-board/

What you will gain are two things:

unlimited Breakpoints and the option to use Segger´s Ozone Debugger which is very helpful when there is a need to debug low level issues.

Debugging in Lazarus works as described by Christo for all three products (Jlink, STlink V2 and China clone).

I do all my debugging on the mac, but i am sure it works exactly the same on windows and linux.

Dimitrios has submitted a patch to Lazarus that fixes a few issues in the Gnu Remote Debugger, so you will need to use trunk Lazarus for best experience.

I can provide a patch that is tailored to work with JLink, but when Dimitrios Patch has already made it to trunk then my changes are only cosmetics for easier configuration.

You also need an arm-none-eabi-gdb binary for debugging, the gdb provided with lazarus only works with x86/x64 code.

One ladt comment on the gdbserver, with jlink you can use Segger´s precompiled gdbserver, for stlink you can use texane:
https://github.com/texane/stlink

[d.ioannidis]

Hi,

  currently AFAIK, one limitation in the tool chain, is that the compiler hardcodes the file extension as .elf and lazarus and remote gdbmidebugger used with arm-gdb, avr-agdb etc is not aware for this. They search for the filename without the extension.

  Martin is aware of this and AFAIK, he is working for a solution.

  If you want I can share my patch that inspired Martin work ( which works  for me ) but I'm sure that Martin's solution will be superior.

  If you don't want to patch Lazarus you could go to the .gdinit file path i.e. :

uncheck the Debugger_Remote_downloadexe and create a file with the following inside :

define target hookpost-remote
file "path/to/file/name.elf"
load
end

and in the tools -> options - > debugger  in Debugger_Startup_Options you put something like the following :

-ex "set remotetimeout 60" -iex "dir/who/has/the/.gdbinit_file" -ix full/path/to/the/.gdbinit_file

notice that the pathseperator is forward slash "/" in the paths ...

[SymbolicFrank]

@ccrause: Thanks, that was the info I was looking for. I'll post what I did when it works.

@MiR: I have all three variants, but I'm using an STM32F401 and official (at least with the logo) ST-Link v2. Both the ST-Link and the discovery boards already seem to do all those things, so I'm not sure it would be an improvement.

@Dimitrios: Thanks, yes, that is exactly what is going wrong!

I made the following file:

Code: [Select]

define target hookpost-remote
file "D:/Projects/FROS/test.elf"
load
end
saved it as

Code: [Select]

D:\Projects\FROS\gdbinit.conf
(I first put it in the ST-Link dir, but that didn't seem to work, it has to be in the project dir.)

And I added the folowing line to Debugger_startup_options:

Code: [Select]

-ex "set remotetimeout 60" -iex "d:/projects/FROS" -ix d:/projects/FROS/gdbinit.conf
That gives the following error:

Code: [Select]

Initialization output:
&"\nwarning: "
&"bad breakpoint number at or near ':/projects/FROS'\n"
=cmd-param-changed,param="remotetimeout",value="60"
I would like to try your patch, if I can get it to work with fpcupdeluxe.

Btw, does this program the device? In your picture, the Debugger_Remote_downloadexe is still checked.


Edit: I found an open-source GDB server (st-util), but that takes over the port, so I cannot use a separate flash prog at the same time. There is an ST-Server which should allow multiple access, but it is incompatible with the GDB server. Also, starting the GDB server from a command-line doesn't finish, so I cannot start one automatically: I have to check if it still works and start it if it doesn't.

[d.ioannidis]

Hi,

That gives the following error:

Code: [Select]

Initialization output:
&"\nwarning: "
&"bad breakpoint number at or near ':/projects/FROS'\n"
=cmd-param-changed,param="remotetimeout",value="60"

This seems to me that there is some inconsistency in debug information and the sources.

I would like to try your patch, if I can get it to work with fpcupdeluxe.

Sure, here it is :

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

1. Index: components/lazdebuggergdbmi/gdbmidebugger.pp
2. ===================================================================
3. --- components/lazdebuggergdbmi/gdbmidebugger.pp   (revision 61423)
4. +++ components/lazdebuggergdbmi/gdbmidebugger.pp   (working copy)
5. @@ -2030,15 +2032,29 @@
6.    if DebuggerState = dsError then Exit;
7.  
8.    S := FTheDebugger.ConvertToGDBPath(FTheDebugger.FileName, cgptExeName);
9. -  Result := ExecuteCommand('-file-exec-and-symbols %s', [s], R);
10. -  if not Result then exit;
11. +  ExecuteCommand('-file-exec-and-symbols %s', , R, []);
12. +  if R.State = dsError then
13. +  begin
14. +    SetDebuggerState(dsIdle);
15. +    FTheDebugger.FileName := FTheDebugger.FileName + '.elf';
16. +    S := FTheDebugger.ConvertToGDBPath(FTheDebugger.FileName, cgptExeName);
17. +    Result := ExecuteCommand('-file-exec-and-symbols %s', , R);
18. +    if not Result then exit;
19. +  end;
20.    {$IFDEF darwin}
21.    if  (R.State = dsError) and (FTheDebugger.FileName <> '')
22.    then begin
23. +    SetDebuggerState(dsIdle);
24.      S := FTheDebugger.FileName + '/Contents/MacOS/' + ExtractFileNameOnly(FTheDebugger.FileName);
25.      S := FTheDebugger.ConvertToGDBPath(S, cgptExeName);
26. -    Result := ExecuteCommand('-file-exec-and-symbols %s', , R);
27. -    if not Result then exit;
28. +    ExecuteCommand('-file-exec-and-symbols %s', , R, []);
29. +    if R.State = dsError then
30. +    begin
31. +      FTheDebugger.FileName := FTheDebugger.FileName + '.elf';
32. +      S := FTheDebugger.ConvertToGDBPath(FTheDebugger.FileName, cgptExeName);
33. +      Result := ExecuteCommand('-file-exec-and-symbols %s', , R);
34. +      if not Result then exit;
35. +    end;
36.    end;
37.    {$ENDIF}
38.  

Btw, does this program the device? In your picture, the Debugger_Remote_downloadexe is still checked.

Yes, cause with the above changes the gdbmmidebugger can upload the firmware through the avr/arm-gdb, so you don't need the .gdbinit file anymore ...

regards

[d.ioannidis]

Hi,

< snip >

Edit: I found an open-source GDB server (st-util), but that takes over the port, so I cannot use a separate flash prog at the same time. There is an ST-Server which should allow multiple access, but it is incompatible with the GDB server. Also, starting the GDB server from a command-line doesn't finish, so I cannot start one automatically: I have to check if it still works and start it if it doesn't.

  I'm not very familiar with ARM ( and particular with ST ) but when I played a little with a atsmad21g18a mcu ( standalone IC on breadboard not a dev board ) I was able to debug / upload with a arm-none-eab-gdb,  medbg as hardware debugger ( also in a standalone IC in a breadboard with a SWD firmware ) .

( you can search fpc-devel for my messages cause I had some problems with the arm toolchain version's ).
 
  IMHO, if you can upload and start a debug session with arm-none-eabi-gdb from command line then you can try my patch for Lazarus debugging ... I'm sure MiR, can help you more because AFAIK, is more knowledgeable in ARM's and/ or ST, Segger hardware debugger tools .

regards,

[Martin_fr]

  currently AFAIK, one limitation in the tool chain, is that the compiler hardcodes the file extension as .elf and lazarus and remote gdbmidebugger used with arm-gdb, avr-agdb etc is not aware for this. They search for the filename without the extension.

  Martin is aware of this and AFAIK, he is working for a solution.

I just had some minor changes, to keep other things working.

I am still waiting for your feedback, if my changes work for you, in which case I will add them.

A version with the patch can be found here: https://github.com/User4martin/lazarus/tree/f-gdbmi-avr

[d.ioannidis]

Hi,

  currently AFAIK, one limitation in the tool chain, is that the compiler hardcodes the file extension as .elf and lazarus and remote gdbmidebugger used with arm-gdb, avr-agdb etc is not aware for this. They search for the filename without the extension.

  Martin is aware of this and AFAIK, he is working for a solution.

I just had some minor changes, to keep other things working.

I am still waiting for your feedback, if my changes work for you, in which case I will add them.

A version with the patch can be found here: https://github.com/User4martin/lazarus/tree/f-gdbmi-avr

Martin apologies for the delay  . I'll do it tonight.

regards,

[SymbolicFrank]

I added your patch to fpcupdeluxe and recompiled (the custom 2.1.0 version from DonAlfredo), but it still gives the same error. Should this also fix it for ARM, or only for AVR? Or isn't it compatible with this version? And if so, which one do I need?

The GDB server is the same as from MiR's post, it seems to work. Otherwise I should update the firmware as he suggests, but I would like to fix the filename bug first.

[d.ioannidis]

Hi,

I added your patch to fpcupdeluxe and recompiled (the custom 2.1.0 version from DonAlfredo), but it still gives the same error. Should this also fix it for ARM, or only for AVR? Or isn't it compatible with this version? And if so, which one do I need?

< snip >

  The patch was created against 25/6/2019 lazarus trunk. I didn't test it in other versions.

  AFAIK, the embedded fpc compiler creates the files with .elf extension for all embedded targets ( I just checked for arm, avr and mips ).This patch try to solve the missing .elf extension problem by a "if file not found try a filename with .elf extension" logic ... It's not an ARM or AVR only thing ...

  As currently don't have access to my fpc dev pc ( until late tonight ), is it possible to post how did you configure the debugger and the information of the debug output window ?

regards,

[SymbolicFrank]

I found the ARM debugger (as MiR said) in the ARM/bin directory from my Arduino installation. Debugging works in the Arduino IDE.

[ccrause]

...
and in the tools -> options - > debugger  in Debugger_Startup_Options you put something like the following :

-ex "set remotetimeout 60" -iex "dir/who/has/the/.gdbinit_file" -ix full/path/to/the/.gdbinit_file

...
And I added the folowing line to Debugger_startup_options:

Code: [Select]

-ex "set remotetimeout 60" -iex "d:/projects/FROS" -ix d:/projects/FROS/gdbinit.conf
That gives the following error:

Code: [Select]

Initialization output:
&"\nwarning: "
&"bad breakpoint number at or near ':/projects/FROS'\n"
=cmd-param-changed,param="remotetimeout",value="60"

Perhaps -iex "d:/projects/FROS" option is supposed to be -d "d:/projects/FROS"? The -iex option takes a single gdb command as parameter according to the
documentation.

Since you call a command file anyway, perhaps just put all your commands in that one file and call with -ix?

[d.ioannidis]

Hi,

I found the ARM debugger (as MiR said) in the ARM/bin directory from my Arduino installation. Debugging works in the Arduino IDE.

could you make a copy of your firmware file D:/Projects/FROS/test.elf and rename it without the extension i.e. D:/Projects/FROS/test and give it a try ?

Just to be sure that the remote gdbmidebugger -> arm-none-eabi-gdb -> stlink ( ? ) listening in port 4242 - > device works ...

EDIT : Also you could post the information from View -> IDE Internals -> Debug Output window.

regards,

[SymbolicFrank]

That seems to run, but it gives the following error (multiple times):

Code: [Select]

The GDB command:
"-break-delete 2"
returned the error:
",msg="Cannot execute this command while the target is running.\nUse the \"interrupt\" command to stop the target\nand then try again.""

I also added a picture of the debugging settings.

Edit: added debug output.