Programming and debugging

[d.ioannidis]

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

Good ! Most probably my patch isn't compatible with this Lazarus version ...

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.""


OK. I think ( if I remember well ) that I had this problem and I had to use a specific arm-none-eabi-version ... I ended up using this  https://github.com/gnu-mcu-eclipse/arm-none-eabi-gcc/releases/tag/v8.2.1-1.2 .

Search in fpc devel for the thread with subject "Cortex-M0 (SAMD21G18A) and gcc-arm-none-eabi-8-2018-q4-major-win32".

EDIT : Ignore the above  ... It was for a different error ....

I also added a picture of the debugging settings.

Please see above ... The Debug Output window information I meant ...

[d.ioannidis]

Hi,

< snip >

Edit: added debug output.

hmmm, I don't see anywhere in the debug ouput a command for uploading the firmware ...

Which lazarus version and fpc version do you have, to try to reproduce your environment  ?

regards,

[Martin_fr]

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 have to check what happened there.

Can you test if the "pause" button works?

If you have the "view"  > "ide internals" > "debug output" open and press the pause button, you should see that the IDE sends "interrupt" to gdb. And then your app should be paused (and you probably see the asm win, unless a source pos is found)

Please also re-run the error, but with a full logfile: https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips#Log_info_for_debug_session
    Start Lazarus with the following options:

Code: [Select]

--debug-log=LOG_FILE  --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORS
Thanks

[d.ioannidis]

Hi,

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 have to check what happened there.

< snip >

AFAIU, one issue with the embedded platforms that gdbmmidebugger doesn't take in account, is that their app / firmware always "run" ...

I assume, IMHO, this is why, all over internet, a lot of people use a combination of gdb startup options and a gdbinit file i.e.:

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

1. define target hookpost-remote
2. file "D:/Projects/FROS/test.elf"
3. load
4. monitor halt
5. break main
6. monitor reset
7. end

regards,

[SymbolicFrank]

Ok, I tried all the above. I added the new logfile.

Pausing the program isn't going to work, as it is only this:

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

1. program test;
2.  
3. begin
4.   asm
5.      mov r0, #0
6.   end;
7. end.

Using the new gdb-file generates the same error about the invalid breakpoint and then complains multiple times that the debugger isn't running.

I'm using the first working embedded version from DonAlfredo as installed by fpcupdeluxe, as that was the first version I could find that actually worked. It is Lazarus version 2.1.0.

I have changed multiple things in the fpc target cpu/platform files (added microcontrollers, changed the FPU settings, created target file), but I'm now using a safe, supported controller, so I could use the original fpc version. That only removes the FPU support.

[SymbolicFrank]

I changed the program to this:

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

1. program test;
2.  
3. var
4.   i: Integer;
5. begin
6.   i := 0;
7.  
8.   while True do
9.   begin
10.     i += 1;
11.     if i = MAXINT then Break;
12.   end;
13. end.

But it never gets far enough to actually start running it. It now gives this error again:

Code: [Select]

The GDB command:
"-break-delete 4"
returned the error:
",msg="Cannot execute this command while the target is running.\nUse the \"interrupt\"

[ccrause]

Ok, I tried all the above. I added the new logfile.

Code: Text  [Select][+][-]

1. =thread-group-added,id="i1"
2. &"\nwarning: "
3. &"bad breakpoint number at or near ':/projects/FROS'\n"
4. =cmd-param-changed,param="remotetimeout",value="60"

Seems like there is still a problem with one of the initialize options passed to gdb.

Code: Text  [Select][+][-]

1. <-exec-continue &>
2. ^running
3. *running,thread-id="all"
4. (gdb)
5. (gdb)
6. <-break-delete 3>
7. ^done

The double (gdb) response seems strange, perhaps this is confusing gdbmidebugger.  I would expect that gdbmidebugger would wait for a message similar to *stopped,reason="breakpoint-hit" before starting to delete breakpoints.  See this example output from gdb/mi.

Could you also attach the full debug log file as per Martin's post:

Code: [Select]

--debug-log=LOG_FILE  --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORSThis option must be passed to Lazarus as a command line option.

[d.ioannidis]

Hi,

< snip >

Seems like there is still a problem with one of the initialize options passed to gdb.

Code: Text  [Select][+][-]

1. <-exec-continue &>
2. ^running
3. *running,thread-id="all"
4. (gdb)
5. (gdb)
6. <-break-delete 3>
7. ^done

The double (gdb) response seems strange, perhaps this is confusing gdbmidebugger.  I would expect that gdbmidebugger would wait for a message similar to *stopped,reason="breakpoint-hit" before starting to delete breakpoints.  See this example output from gdb/mi.

< snip >

@ccrause I missed that ...

@SymbolicFrank add the -ex "set remotetimeout 60" in debugger_startup_options and I think it will work ...

regards,

[MiR]

I will have a look at my Windows computer this evening (I guess I will first need to remove the spider webs and the dust on that machine ...)

There is one option that you could try before, please connect one of the nucleo boards you own, with those boards you can be sure that the reset pin is properly connected and that you do not have an issue because of some missing cable (you wrote that debugging worked with ST-Link's IDE, so the chances are pretty slim, but still perhaps worth a try.)
 You can also make sure that the STLink firmware on your STLink/Nucleos/Discovery devices is latest/greatest, connect them to STM32CubeProgrammer and it will allow you to check/upgrade the firmware.

 Can you please tell me which Nucleo/Discovery board you own, I can then do the setup with the same board.

Did you build latest Texane (STLink) or did you grab a prebuilt version from the internet?
If 2nd case, please provide the link so that I can use the same version.

Same with arm-none-eabi-gdb, which version do you use, there are some versions that work well, others are not that good. This will bite you later during debugging, so let's make this sure right now.

Michael

[SymbolicFrank]

Could you also attach the full debug log file as per Martin's post:

Code: [Select]

--debug-log=LOG_FILE  --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORSThis option must be passed to Lazarus as a command line option.

I did that, it's in the previous post.

[SymbolicFrank]

I will have a look at my Windows computer this evening (I guess I will first need to remove the spider webs and the dust on that machine ...)

I can use Linux as well, I just figured it would be easier on Windows. Just tell me which Lazarus version to install. Or if you like, what I have to install to make it work. I do have the fpcupdeluxe version installed on Linux Mint Cinnamon.

There is one option that you could try before, please connect one of the nucleo boards you own, with those boards you can be sure that the reset pin is properly connected and that you do not have an issue because of some missing cable (you wrote that debugging worked with ST-Link's IDE, so the chances are pretty slim, but still perhaps worth a try.)
 You can also make sure that the STLink firmware on your STLink/Nucleos/Discovery devices is latest/greatest, connect them to STM32CubeProgrammer and it will allow you to check/upgrade the firmware.

 Can you please tell me which Nucleo/Discovery board you own, I can then do the setup with the same board.

I have a NUCLEO-F767ZI and a NUCLEO-L432KC, but both aren't supported in the Free Pascal versions I tried. I did add the second device, but decided it was safer to buy an average, fully supported one. That's why I went with the STM32F401CC and a separate ST-Link v2.

Did you build latest Texane (STLink) or did you grab a prebuilt version from the internet?
If 2nd case, please provide the link so that I can use the same version.

Same with arm-none-eabi-gdb, which version do you use, there are some versions that work well, others are not that good. This will bite you later during debugging, so let's make this sure right now.

Michael

I first had a different version of the Texane utils, but I grabbed the newest Windows binaries (v1.3.0) from the link you posted. And I grabbed the arm-none-eabi-gdb from my Arduino install. It doesn't show a version, so if you know a better version, please post a link.

I just updated the ST-Link to V2.J34.S7. If you think things work better with the version you posted I'll update to that.

Edit: with the SWD debugging, normally a soft reset is used, but I could solder a header and connect it to the reset pin.

[ccrause]

Could you also attach the full debug log file as per Martin's post:

Code: [Select]

--debug-log=LOG_FILE  --debug-enable=DBG_CMD_ECHO,DBG_STATE,DBG_DATA_MONITORS,DBGMI_QUEUE_DEBUG,DBGMI_TYPE_INFO,DBG_ERRORSThis option must be passed to Lazarus as a command line option.

I did that, it's in the previous post.

That looks like a copy of the Lazarus Debug Output window. The log file has much more (mostly about internal states of Lazarus\gdbmidebugger) and should contain a bunch of the following type of lines:

Code: Text  [Select][+][-]

1. << TCmdLineDebugger.ReadLn "(gdb) "
2. >> TCmdLineDebugger.SendCmdLn "-break-delete 3"
3. << TCmdLineDebugger.ReadLn "^done"
4. << TCmdLineDebugger.ReadLn "(gdb) "
5. DebuggerState: Setting to dsRun, from dsStop
6. DebuggerState: Finished dsRun
7. >> TCmdLineDebugger.SendCmdLn "info address FPC_RAISEEXCEPTION"
8. << TCmdLineDebugger.ReadLn "&"info address FPC_RAISEEXCEPTION\n""
9. << TCmdLineDebugger.ReadLn "&"No symbol \"FPC_RAISEEXCEPTION\" in current context.\n""

[Martin_fr]

I saw it.

And indeed there seems to be an issue in the debugger startup code.... I'll be looking into that.

[SymbolicFrank]

Ah, sorry. Found it.

Btw, I'm now using this board: https://www.aliexpress.com/item/33014539711.html

I also have these:

https://robotdyn.com/stm32-arm-arduino-mini-system-dev-board-blue-pill-with-arduino-bootloader.html
https://www.aliexpress.com/item/32996982658.html

And the two Nucleo boards:

https://uk.farnell.com/stmicroelectronics/nucleo-l432kc/dev-board-nucleo-32/dp/2580786
https://uk.farnell.com/stmicroelectronics/nucleo-f767zi/dev-board-nucleo-32-mcu/dp/2546569

[SymbolicFrank]

I saw it.

And indeed there seems to be an issue in the debugger startup code.... I'll be looking into that.

Nice!