Programming and debugging

[MiR]

OK, I just arrived at home, lets start. I will update this post based on my and your progress, so please recheck...

I also have the stm32l432 board, so let's use this one.

First step is to make the board work with GDB.

I will try to be as complete as possible in the explanations, so please forgive me if I repeat stuff you already did.

Download texane/stlink binary for Windows:

Man page on github:

https://github.com/texane/stlink

Link to the Downloads:

https://github.com/texane/stlink/releases/tag/1.3.0

Now download a recent GDB if you do not alread have one:

https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads

For building embedded code this version of the tools unfortunately does not work, you will need to download an older version on Windows:

https://developer.arm.com/-/media/Files/downloads/gnu-rm/5_3-2016q1/gcc-arm-none-eabi-5_3-2016q1-20160330-win32.exe?revision=d07f533b-4a72-49ef-adbf-5302fb396073?product=GNU%20Arm%20Embedded%20Toolchain,32-bit,,Windows,5-2016-q1-update


Direct link:

https://developer.arm.com/-/media/Files/downloads/gnu-rm/5_3-2016q1/gcc-arm-none-eabi-5_3-2016q1-20160330-win32.exe?revision=d07f533b-4a72-49ef-adbf-5302fb396073?product=GNU%20Arm%20Embedded%20Toolchain,32-bit,,Windows,5-2016-q1-update

Now install the toolchain, in the end you will see an opened cmd-window, keep that open, we will need it in a moment.

Unpack the contents of stlink-1.3.0-win64.zip and copy all the files from the bin directory to some place where you want to keep them. Only the binaries are needed, the rest does not matter.

Now connect the Board to your computer and start

st-util.exe

it will detect your board and display this message:

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

1. st-util.exe
2. st-util 1.3.0
3. 2019-07-03T21:33:32 INFO C:\Users\Jerry\Desktop\stlink-master\src\common.c: Loading device parameters....
4. 2019-07-03T21:33:32 INFO C:\Users\Jerry\Desktop\stlink-master\src\common.c: Device connected is: L43x device, id 0x10016435
5. 2019-07-03T21:33:32 INFO C:\Users\Jerry\Desktop\stlink-master\src\common.c: SRAM size: 0xc000 bytes (48 KiB), Flash: 0x40000 bytes (256 KiB) in pages of 2048 bytes
6. 2019-07-03T21:33:32 INFO C:\Users\Jerry\Desktop\stlink-master\src\gdbserver\gdb-server.c: Chip ID is 00000435, Core ID is  2ba01477.
7. 2019-07-03T21:33:32 INFO C:\Users\Jerry\Desktop\stlink-master\src\gdbserver\gdb-server.c: Listening at *:4242...
8.  

Now activate the cmd window that was left open by the installation of the arm-tools

cd bin

and now start gdb:

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

1. arm-none-eabi-gdb.exe
2.  
3. GNU gdb (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 8.2.50.20181213-git
4. Copyright (C) 2018 Free Software Foundation, Inc.
5. ...
6. For help, type "help".
7. Type "apropos word" to search for commands related to "word".
8.  

in gdb enter:

target remote localhost:4242

You will now see communication between texane and gdb.

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

1. (gdb) target remote localhost:4242
2. Remote debugging using localhost:4242
3. warning: No executable has been specified and target does not support
4. determining executable automatically.  Try using the "file" command.
5. 0x08004420 in ?? ()
6. (gdb)

All good until here?

Lets continue.....


Next step is to blink something....

Download this file:

http://temp.michael-ring.org/Blinky.elf

Put it in an easy to reach place (For me this is my Desktop) and then go back to gdb:

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

1. (gdb) file /Users/ring/Desktop/Blinky.elf
2. A program is being debugged already.
3. Are you sure you want to change the file? (y or n) y
4. Reading symbols from /Users/ring/Desktop/Blinky.elf...

now we load the file to the controller:

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

1. (gdb) load
2. Loading section .text, size 0x193c lma 0x8000000
3. Loading section .data, size 0x105 lma 0x800193c
4. Start address 0x8000a38, load size 6721
5. Transfer rate: 16 KB/sec, 3360 bytes/write.

and now we start the program:

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

1. (gdb) cont
2. Continuing.

You should now see the LED blinking on your Board. Congratulations, you just ran your first Freepascal Application on the board!!!

Keep me posted if you also succeeded, meanwhile I will now recompile Lazarus with the patches from Martin.....

OK. Let's build lazarus with the latest tricks...

I have Lazarus installed in C:\azarus, the fpc came with this Lazarus, use your fpc from another path if you need....

First, let's download the trunk version of Lazarus,you need trunk to be able to upload your binary to your device from within Lazarus:

either do:
svn co http://svn.freepascal.org/svn/lazarus/trunk lazarus-stm32

or download sources from here:

https://wiki.lazarus.freepascal.org/Lazarus_Snapshots_Downloads

unpack it in a convenient place (Desktop for me) and then change in the top-directory:

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

1. cd lazarus-f-gdbmi-avr

and do the build:

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

1. PATH=C:\Lazarus\fpc\3.0.4\bin\x86_64-win64
2. make

Lazarus working? Great!!!!

Let's build a fresh fpc with support for the stm32l432kc:


Download my patches for fpc here:

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

Download trunk of fpc here:

ftp://ftp.freepascal.org/pub/fpc/snapshot/trunk/source/fpc.zip

in case you are unable to apply my patches you can download a snapshot from 04.07.2019 here:

http://temp.michael-ring.org/fpc-stm32.zip

and unpack fpc in a convenient place, Desktop for me....
put the downloaded patch in Desktop. Then do:

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

1. cd <name of your fpc-directory-you-just-downloaded>

if you need to apply the patch for extended stm32 support run:

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

1. patch -p0 <..\fpc-trunk-stm32l4.patch
2. patching file compiler/arm/cpuinfo.pas
3. Hunk #1 succeeded at 334 (offset 15 lines).
4. Hunk #2 succeeded at 964 (offset 15 lines).
5. patching file compiler/systems/t_embed.pas
6. Hunk #1 succeeded at 471 (offset 7 lines).
7. patching file rtl/embedded/Makefile
8. Hunk #1 succeeded at 361 (offset -2 lines).
9. patching file rtl/embedded/Makefile.fpc
10. patching file rtl/embedded/arm/stm32l431xx.pp
11. patching file rtl/embedded/arm/stm32l432xx.pp
12. patching file rtl/embedded/arm/stm32l433xx.pp
13. patching file rtl/embedded/arm/stm32l442xx.pp
14. patching file rtl/embedded/arm/stm32l443xx.pp
15. patching file rtl/embedded/arm/stm32l451xx.pp
16. patching file rtl/embedded/arm/stm32l452xx.pp
17. patching file rtl/embedded/arm/stm32l462xx.pp
18. patching file rtl/embedded/arm/stm32l471xx.pp
19. patching file rtl/embedded/arm/stm32l475xx.pp
20. patching file rtl/embedded/arm/stm32l476xx.pp
21. patching file rtl/embedded/arm/stm32l485xx.pp
22. patching file rtl/embedded/arm/stm32l486xx.pp
23. patching file rtl/embedded/arm/stm32l496xx.pp
24. patching file rtl/embedded/arm/stm32l4a6xx.pp
25. patching file rtl/embedded/arm/stm32l4r5xx.pp
26. patching file rtl/embedded/arm/stm32l4r7xx.pp
27. patching file rtl/embedded/arm/stm32l4r9xx.pp
28. patching file rtl/embedded/arm/stm32l4s5xx.pp
29. patching file rtl/embedded/arm/stm32l4s7xx.pp
30. patching file rtl/embedded/arm/stm32l4s9xx.pp
31.  
32.  

all good?

For convenience we now go to the bin directory of the Arm Bintools ( C:\Program Files (x86)\GNU Tools ARM Embedded\5.3 2016q1\bin ) and copy the content of the bin directory to c:\pp\bin
Now only take the new arm-none-eabi-gdb.exe from the bin directory of the Arm Bintools ( C:\Program Files (x86)\GNU Tools ARM Embedded\8 2018-q4-major\bin ) and copy it to c:\pp\bin
create the directory if it does not exist.

now let's build the crosscompiler:

make clean buildbase installbase CROSSINSTALL=1 OS_TARGET=embedded CPU_TARGET=arm SUBARCH=armv7em BINUTILSPREFIX=C:\pp\bin\arm-none-eabi-

We are now VERY close.... (hopefully....)

Time to configure Lazarus:

For simplicity, go to the directory where you built the new lazarus and open a shell:

then add the path to the freshly build crosscompiler:

PATH=C:\Lazarus\fpc\3.0.4\bin\x86_64-win64;C:\pp\bin\x86_64-win64

and start lazarus:

startlazarus

this makes sure that lazarus finds the crosscompiler.

Now apply the config changes as displayed in the screenshots, please note that the 4th screenshot is in another posting because I can only upload 250k per post.

After doing this configuration I created this simple program:

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

1. program project1;
2. var
3.   a,b: integer;
4. begin
5.   a := 10;
6.   b :=20;
7. end.  

then I make sure that st-util.exe is running and I start debugging.....

Works like a charm! (At least most of the time, in the die-hard cases I use ozone.......

E.O.M.

[SymbolicFrank]

I will try to be as complete as possible in the explanations, so please forgive me if I repeat stuff you already did.

Thanks! That is the best way to do it!

<snip>

I did all that, and it totally worked. 

[d.ioannidis]

Hi,

< snip >

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

< snip >

Again, sorry for the delay ...

Just tested it and unfortunately the problem persist. I emailed to you my feedback and logs.

EDIT: I tested wrong branch . Indeed the .elf extension problem is fixed .

Thank you very much Martin !!

regards,

[SymbolicFrank]

MiR: Building OK.

[Martin_fr]

Comited to svn trunk

[SymbolicFrank]

MiR:

Starting Lazarus in the previous step gave a bunch of configuration errors (which is common with the current fpcupdeluxe versions as well), but it ran fine.

Applying the patches didn't work as expected:

Code: [Select]

C:\Data\Apps\fpcupdeluxe\fpc-embedded>patch -p1 < fpc-trunk-stm32l4.patch
patching file `compiler/arm/cpuinfo.pas'
Assertion failed: hunk, file patch.c, line 321
I had to change the line because I put the patches in the fpc-embedded directory, but putting them in the top directory gave the same error. The patch.exe is from the fpc bin directory, as I put that as the first entry in my PATH.

Edit: this didn't work either:

Code: [Select]

C:\Data\Apps\fpcupdeluxe\fpc-embedded>C:\Data\Apps\fpcupdeluxe\fpc\bin\x86_64-win64\patch -p1 <..\fpc-trunk-stm32l4.patch
patching file `compiler/arm/cpuinfo.pas'
Assertion failed: hunk, file patch.c, line 321
Edit2:

Code: [Select]

C:\Data\Apps\fpcupdeluxe\fpc-embedded>dir compiler\arm\cpuinfo.pas
 Volume in drive C is System
 Volume Serial Number is F664-BA90

 Directory of C:\Data\Apps\fpcupdeluxe\fpc-embedded\compiler\arm

2019-06-28  12:21            90.847 cpuinfo.pas
               1 File(s)         90.847 bytes
               0 Dir(s)  79.545.221.120 bytes free

[d.ioannidis]

Hi,

MiR:

Starting Lazarus in the previous step gave a bunch of configuration errors (which is common with the current fpcupdeluxe versions as well), but it ran fine.

Applying the patches didn't work as expected:

Code: [Select]

C:\Data\Apps\fpcupdeluxe\fpc-embedded>patch -p1 < fpc-trunk-stm32l4.patch
patching file `compiler/arm/cpuinfo.pas'
Assertion failed: hunk, file patch.c, line 321
I had to change the line because I put the patches in the fpc-embedded directory, but putting them in the top directory gave the same error. The patch.exe is from the fpc bin directory, as I put that as the first entry in my PATH.

Edit: this didn't work either:

Code: [Select]

C:\Data\Apps\fpcupdeluxe\fpc-embedded>C:\Data\Apps\fpcupdeluxe\fpc\bin\x86_64-win64\patch -p1 <..\fpc-trunk-stm32l4.patch
patching file `compiler/arm/cpuinfo.pas'
Assertion failed: hunk, file patch.c, line 321
Edit2:

Code: [Select]

C:\Data\Apps\fpcupdeluxe\fpc-embedded>dir compiler\arm\cpuinfo.pas
 Volume in drive C is System
 Volume Serial Number is F664-BA90

 Directory of C:\Data\Apps\fpcupdeluxe\fpc-embedded\compiler\arm

2019-06-28  12:21            90.847 cpuinfo.pas
               1 File(s)         90.847 bytes
               0 Dir(s)  79.545.221.120 bytes free

the patches's inside paths, starts with fpc-tmp2/ and fpc-tmp/ see :

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

1. diff -Naur fpc-tmp2/compiler/arm/cpuinfo.pas fpc-tmp/compiler/arm/cpuinfo.pas
2. --- fpc-tmp2/compiler/arm/cpuinfo.pas   2018-09-10 23:25:34.000000000 +0200
3. +++ fpc-tmp/compiler/arm/cpuinfo.pas    2018-09-10 23:11:29.000000000 +0200

If you delete those "fpc-tmp2/" and "fpc-tmp/" ( i.e. try to do a replace "fpc-tmp2/" and "fpc-tmp/" to "" in i.e. Notepad++ ) then the patches works just fine ...

regards,

[SymbolicFrank]

I deleted all the occurrences of fpc-tmp/ and fpc-tmp2/, the files exist, "patch --help" works as expected, I tried it with a administrator cmd and another patch.exe, but they all crash with that same error.

[MiR]

Here'S the last screenshot.

Please re-read the text, the version of arm tools I asked you to download does not work properly on 64bit windows, please take the other version mentionen in the post.

On patching:

Please use a plain version of fpc as I wrote, Alfred has included my Class Library (mbf) and my patches for atmel Cortex-M Chips into fpcupdeluxe, it may be that this is the reason that patching fails.

Also, I am not sure if your patch is compatible to the unix version of patch, when you have cygwin installed than please download the cygwin version of patch. the -p1 parameter does exactly what you guys did manually, it strips away the first path in the patch.

[d.ioannidis]

Hi,

I deleted all the occurrences of fpc-tmp/ and fpc-tmp2/, the files exist, "patch --help" works as expected, I tried it with a administrator cmd and another patch.exe, but they all crash with that same error.

strange... I assume that you did it at the top level fpc directory.

OTOH, I didn't try the patch.exe, I used TortoiseSVN and it worked ...

[MiR]

Worst case I can upload a patched version of fpc to my rootserver, let me know...

Time for a cold beer, please keep me posted on your progress, we can continue tomorrow if there are still issues open.

[Martin_fr]

Code: [Select]

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

I will need to setup my own "remote" test environment (actually local gdbserver might do). And then do some extended testing. This may take a while.

I do have a hunch what it might be, and prepared a potential fix (but I could not test it yet myself, so no knowing if it will help).
You can find it at https://github.com/User4martin/lazarus/tree/f-gdbmi-async-processing

---
There is also some very old code that appears to be an attempt to deal with the same or similar issue. It can be activated with -dDBG_ASYNC_WAIT but only in the version without my patch. I have not even tried if it compiles. I do not recommand it.

[SymbolicFrank]

Ok, it is getting late. I did notice the 32-bits thing, but the patch that is first in my path is the one from the fpcupdeluxe fpc bin. That's probably the problem. Anyway, I'll repeat everything tomorrow with fresh versions and report how it goes.

Thanks a lot for all the help so far!

[SymbolicFrank]

I did some research. And decide to use fpc-trunk-stm32all.patch to fix them all at the same time. (And I enabled the correct floating-point unit for the chips I own.)

First, as Martin checked in a new trunk, I tried to use fpcupdeluxe. Installing the embedded version with the patch from MiR didn't work. Installing trunk with embedded arm cross-compiler and the patch didn't work either.

Next up, applying the patch with patch.exe: all attempts failed.

The only patch utility that actually worked was TortoiseSVN merge, as Dimitrios said. But I could only apply it to the fpcupdeluxe versions, as I downloaded the MiR versions and Tortoise complained that they weren't valid. Applying the patch showed that there are large differences between the two codebases. Many files are different and in different locations, or missing. It produced lots of errors, and I had to split the patch to make it work somewhat. But that isn't going to produce a functional IDE.

Next up: removing everything FPC and Lazarus related, checkout only clean stuff and everything from MiR, and try again. But first I have some other things to do.

[MiR]

Let me provide you pre-patched versions of Lazarus (actually as of today a zip file of trunk should be enough) and fpc later today, that will be the easiest way to go forward. There is an issue with stm32f1xx patch because of some change that was done to trunk.

I'd recommend to first not include your changes for enabling hardware floating point as the rest of us will use the version without floating point math and it will be difficult to find out if you app crashes and burns because of math or not.

The moment you are sure that all works as you expected (mening you have successfully debugged two or three projects that actually do something meaningful, not my stupid example) I'd recommend to enable floating point math.