Forum > Embedded - ARM

Programming and debugging

(1/33) > >>

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: ---define target hookpost-remote
file "D:/Projects/FROS/test.elf"
load
end
--- End code ---

saved it as


--- Code: ---D:\Projects\FROS\gdbinit.conf
--- End code ---

(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: ----ex "set remotetimeout 60" -iex "d:/projects/FROS" -ix d:/projects/FROS/gdbinit.conf
--- End code ---

That gives the following error:


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

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.

Navigation

[0] Message Index

[#] Next page

Go to full version