I am trying to set up FPC to use the Xtensa-FreeRTOS for ESP8266 by following the instructions at the Xtensa Wiki page (https://wiki.lazarus.freepascal.org/Xtensa#ESP8266).
I have installed the ESP8266-RTOS-SDK and successfully compiled and executed the hello_world example.
But, I get to the Build FPC section and read, "Change into the fpc directory [..]" What fpc directory? I don't see anywhere in the instructions where I was told to create one.
Reading further, in the Compile and run test program section, I read, "Create a hello world program [...]" How do I do that? Is there an example somewhere? Would it be something as simple as:?
program Hello; begin writeln ('Hello, world.'); end.
Some of the SDK has been translated in this project (https://github.com/ccrause/fpc-esp-freertos). Have a look at the examples to see what is possible at the moment. Not fully updated, so feel free to post issues against the project.
Or, how would I translate the FreeRTOS example (main program attached) to FreePascal? Is there an API reference?
Maybe I'm just dense because I find the instructions quite confusing.
Or use fpcupdeluxe which automates the whole process of downloading fpc source and building the cross compiler.fpcupdeluxe load his own (older ?) toolchain and this have some problems with the esp8266. It looks it is more tested for the stm32, not for esp8266. Because it will use the stm32 crosscompiler (lx6) instead of the lx106 crosscompiler.
Indeed not clear, I agree. Xtensa is only supported in the development version of fpc, so a recent copy of the main branch is required. See https://www.freepascal.org/develop.html for different ways to get the development version source - I suggest using git as this way updating the source is relatively easy once configured. Or use fpcupdeluxe which automates the whole process of downloading fpc source and building the cross compiler.Ah, okay. So the "fpc directory" should be the "fpc source directory". Got it.
Some of the SDK has been translated in this project (https://github.com/ccrause/fpc-esp-freertos). Have a look at the examples to see what is possible at the moment. Not fully updated, so feel free to post issues against the project.That looks very interesting. I'll have to delve into it when I have a bit more time.
Using the updated instructions, I have made progress. Compiling ppcrossxtensa finished with no errors.
Now when I tried to compile the 'hello world' test program the first time, the linker complained that it could not find libc_fnano.a and libstdc++.a.
After removing the 'sysroot' directory (which does not exist) from the last compiler option:The linker was able to find libstdc++.a, but still not libc_fnano.a.
-Fl~/esp/xtensa-lx106-elf/xtensa-lx106-elf/sysroot/lib/
libc_nano.a is in ~/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib but not libc_fnano.a, and I don't know where that comes from as I do not find any ESP8266 or FPC source file that refers to it.
This is a dependency change from esp8266-rtos-sdk v3.3 to v3.4, perhaps due to the newer gcc toolchain. I'm busy testing a patch so that the compiler can generate the correct library requirements based on the SDK version.
Edit: proposed fix (https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/115)
Did you add the command line option -WP3.4?
> A fatal error occurred: Invalid head of packet (0x01)
Did you add the command line option -WP3.4?
No, I did not. I didn't realize I needed to. Adding that option appears to have fixed the issue as it compiled and linked with no errors.
(BTW, are these cross-compiler options documented somewhere? All I can find is -Wp which defines "Minimum iOS deployment version" though I'm sure this is for plain-vanilla FPC.)
I proceeded to flash the device (a Devkit v0.9; 2M flash) with:
$IDF_PATH/components/esptool_py/esptool/esptool.py --chip esp8266 --port "/dev/ttyUSB1" --baud 921600 --before "default_reset" --after "hard_reset" write_flash -z --flash_mode "dio" --flash_freq "40m" --flash_size "2MB" 0x0 bootloader.bin 0x10000 hello.bin 0x8000 partitions_singleapp.bin
The result:
esptool.py v2.4.0 Connecting..... Chip is ESP8266EX Features: WiFi MAC: [retracted] Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size... A fatal error occurred: Invalid head of packet (0x01)
Edit:
FYI, I copied partitions_singleapp.bin from ~/esp8266/hello_world/build/ and bootloader.bin from ~/esp8266/hello_world/build/bootloader/
watch out for ModemManager.
Nothing seems obviously wrong with your flash command. Did you manage to flash the SDK example to your board (make flash)? If so, just copy the parameters from there.
esptool.py v2.4.0
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: e8:db:84:99:e5:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0030
Compressed 10432 bytes to 7027...
Wrote 10432 bytes (7027 compressed) at 0x00000000 in 0.7 seconds (effective 128.0 kbit/s)...
Hash of data verified.
Compressed 154160 bytes to 99259...
Wrote 154160 bytes (99259 compressed) at 0x00010000 in 9.1 seconds (effective 134.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 83...
Wrote 3072 bytes (83 compressed) at 0x00008000 in 0.0 seconds (effective 1640.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
~/esp8266/projects> $IDF_PATH/tools/idf_monitor.py --baud 74880 --port /dev/ttyUSB1 hello.elf
--- idf_monitor on /dev/ttyUSB1 74880 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 7040, room 16
tail 0
chksum 0x69
load 0x3ffe8408, len 24, room 8
tail 0
chksum 0xe0
load 0x3ffe8420, len 3324, room 8
tail 4
chksum 0xa3
csum 0xa3
I (40) boot: ESP-IDF v3.4-53-g83517ba1 2nd stage bootloader
I (41) boot: compile time 19:04:49
I (41) qio_mode: Enabling default flash chip QIO
I (49) boot: SPI Speed : 40MHz
I (55) boot: SPI Mode : QIO
I (61) boot: SPI Flash Size : 2MB
I (67) boot: Partition Table:
I (73) boot: ## Label Usage Type ST Offset Length
I (84) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (96) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (107) boot: 2 factory factory app 00 00 00010000 000f0000
I (119) boot: End of partition table
I (125) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1b288 (111240) map
0x40210010: _stext at ??:?
I (176) esp_image: segment 1: paddr=0x0002b2a0 vaddr=0x4022b298 size=0x05984 ( 22916) map
I (184) esp_image: segment 2: paddr=0x00030c2c vaddr=0x3ffe8000 size=0x0002c ( 44) load
I (187) esp_image: segment 3: paddr=0x00030c60 vaddr=0x3ffe8030 size=0x00604 ( 1540) load
I (201) esp_image: segment 4: paddr=0x0003126c vaddr=0x40100024 size=0x0007c ( 124) load
I (215) esp_image: segment 5: paddr=0x000312f0 vaddr=0x401000a0 size=0x04714 ( 18196) load
I (234) boot: Loaded app from partition at offset 0x10000
Nothing seems obviously wrong with your flash command. Did you manage to flash the SDK example to your board (make flash)? If so, just copy the parameters from there.
Yes, the Espressif hello_world example built, flashed, and worked successfully.
By, "the parameters from there," I assume you mean the MENUCONFIG > Serial Flasher configuration params.
I lowered the baud rate to 115200, as you suggested, which also agrees with the Serial Flasher config. It then flashed to the device, but I am not so sure it did so correctly given the output of the monitor command (ie. idf_monitor.py) quoted further below.
Flash output:Quoteesptool.py v2.4.0
Connecting....
Chip is ESP8266EX
Features: WiFi
MAC: e8:db:84:99:e5:64
Uploading stub...
Running stub...
Stub running...
Configuring flash size...
Flash params set to 0x0030
Compressed 10432 bytes to 7027...
Wrote 10432 bytes (7027 compressed) at 0x00000000 in 0.7 seconds (effective 128.0 kbit/s)...
Hash of data verified.
Compressed 154160 bytes to 99259...
Wrote 154160 bytes (99259 compressed) at 0x00010000 in 9.1 seconds (effective 134.8 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 83...
Wrote 3072 bytes (83 compressed) at 0x00008000 in 0.0 seconds (effective 1640.8 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
I then also changed the flash mode to QIO (ie. --flash_mode "qio") to be in agreement with the Serial Flasher. The output from the flash operation and the monitor appears to be the same as with DIO flash mode:
Monitor output:Quote~/esp8266/projects> $IDF_PATH/tools/idf_monitor.py --baud 74880 --port /dev/ttyUSB1 hello.elf
--- idf_monitor on /dev/ttyUSB1 74880 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jan 8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 7040, room 16
tail 0
chksum 0x69
load 0x3ffe8408, len 24, room 8
tail 0
chksum 0xe0
load 0x3ffe8420, len 3324, room 8
tail 4
chksum 0xa3
csum 0xa3
I (40) boot: ESP-IDF v3.4-53-g83517ba1 2nd stage bootloader
I (41) boot: compile time 19:04:49
I (41) qio_mode: Enabling default flash chip QIO
I (49) boot: SPI Speed : 40MHz
I (55) boot: SPI Mode : QIO
I (61) boot: SPI Flash Size : 2MB
I (67) boot: Partition Table:
I (73) boot: ## Label Usage Type ST Offset Length
I (84) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (96) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (107) boot: 2 factory factory app 00 00 00010000 000f0000
I (119) boot: End of partition table
I (125) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1b288 (111240) map
0x40210010: _stext at ??:?
I (176) esp_image: segment 1: paddr=0x0002b2a0 vaddr=0x4022b298 size=0x05984 ( 22916) map
I (184) esp_image: segment 2: paddr=0x00030c2c vaddr=0x3ffe8000 size=0x0002c ( 44) load
I (187) esp_image: segment 3: paddr=0x00030c60 vaddr=0x3ffe8030 size=0x00604 ( 1540) load
I (201) esp_image: segment 4: paddr=0x0003126c vaddr=0x40100024 size=0x0007c ( 124) load
I (215) esp_image: segment 5: paddr=0x000312f0 vaddr=0x401000a0 size=0x04714 ( 18196) load
I (234) boot: Loaded app from partition at offset 0x10000
This must be an antisocial device as it did not say, "Hello".
Try a different baud rate. The bootloader uses a non-standard baud of 74880, but once booted the serial baud is probably 115200 (this is also a configuration setting in menuconfig).
I (250) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1cc70 (117872) map
0x40210010: _stext at ??:?
I (333) esp_image: segment 1: paddr=0x0002cc88 vaddr=0x4022cc80 size=0x0724c ( 29260) map
I (348) esp_image: segment 2: paddr=0x00033edc vaddr=0x3ffe8000 size=0x00544 ( 1348) load
I (356) esp_image: segment 3: paddr=0x00034428 vaddr=0x40100000 size=0x00080 ( 128) load
I (383) esp_image: segment 4: paddr=0x000344b0 vaddr=0x40100080 size=0x050c0 ( 20672) load
I (127) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1b288 (111240) map
0x40210010: _stext at ??:?
I (178) esp_image: segment 1: paddr=0x0002b2a0 vaddr=0x4022b298 size=0x05984 ( 22916) map
I (186) esp_image: segment 2: paddr=0x00030c2c vaddr=0x3ffe8000 size=0x0002c ( 44) load
I (189) esp_image: segment 3: paddr=0x00030c60 vaddr=0x3ffe8030 size=0x00604 ( 1540) load
I (203) esp_image: segment 4: paddr=0x0003126c vaddr=0x40100024 size=0x0007c ( 124) load
I (217) esp_image: segment 5: paddr=0x000312f0 vaddr=0x401000a0 size=0x04714 ( 18196) load
Try a different baud rate. The bootloader uses a non-standard baud of 74880, but once booted the serial baud is probably 115200 (this is also a configuration setting in menuconfig).
I tried multiple different baud rates: 115200, 57600, 38400, 19200, 9600, 4800, 1200. Every rate but 74800 gives me garbage. The Espressif menuconfig is set to flash at 115200 and monitor at 74880.
To see if there were any differences between the Espressif hello_world example operation and my FPC Xtensa operation, I captured the output from flashing and monitoring both projects, respectively.Nothing out of the ordinary here. The differences are both due to differences in main code (as you suspected) and the impact of the fpc RTL code.
The flash output between the two is the same except for the size of the main app written to the device at 0x00010000 as expected.
In the monitor output, the boot mode [boot mode:(3,7) vs boot mode:(3,6)] and the esp_image differ.
I assume the differences in the esp_image are due to the difference in the main app. But, here they are anyway.
hello_world (hello_world_main.c):QuoteI (250) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1cc70 (117872) map
0x40210010: _stext at ??:?
I (333) esp_image: segment 1: paddr=0x0002cc88 vaddr=0x4022cc80 size=0x0724c ( 29260) map
I (348) esp_image: segment 2: paddr=0x00033edc vaddr=0x3ffe8000 size=0x00544 ( 1348) load
I (356) esp_image: segment 3: paddr=0x00034428 vaddr=0x40100000 size=0x00080 ( 128) load
I (383) esp_image: segment 4: paddr=0x000344b0 vaddr=0x40100080 size=0x050c0 ( 20672) load
hello.pp:QuoteI (127) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1b288 (111240) map
0x40210010: _stext at ??:?
I (178) esp_image: segment 1: paddr=0x0002b2a0 vaddr=0x4022b298 size=0x05984 ( 22916) map
I (186) esp_image: segment 2: paddr=0x00030c2c vaddr=0x3ffe8000 size=0x0002c ( 44) load
I (189) esp_image: segment 3: paddr=0x00030c60 vaddr=0x3ffe8030 size=0x00604 ( 1540) load
I (203) esp_image: segment 4: paddr=0x0003126c vaddr=0x40100024 size=0x0007c ( 124) load
I (217) esp_image: segment 5: paddr=0x000312f0 vaddr=0x401000a0 size=0x04714 ( 18196) load
I don't know what else I can do.
You can also download a prebuilt SDK snapshot (that I tested) here: https://github.com/ccrause/fpc-esp-freertos/blob/master/snapshot/fpc-esp8266-idf-3.4-20220107.zip
This snapshot is configured for a baud rate of 115200, so you should see the output of the above test program with a serial monitor configured for 115200 baud. The 1st stage bootloader output is fixed at 74880 baud (or rather depends on the base clock frequency of the module), so the first bit of output will be scrambled, until the 2nd stage bootloader is loaded. Modify the library path to point to the libs folder inside this snapshot (after extracting the contents). This is just to test against my configuration, else we are not looking at the same libraries and we will keep on guessing what the other configuration looks like...
~/esp/fpc/source/compiler/ppcrossxtensa -Fu~/esp/fpc/source/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O3 -Wpesp8266 -WP3.4 test -Fl~/esp/fpc-esp8266-idf-3.4/libs -Fl~/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib/
[garbage] (49) boot: ESP-IDF v3.4-43-ge9516e4c 2nd stage bootloader
I (49) boot: compile time 17:07:40
I (49) boot: SPI Speed : 40MHz
I (53) boot: SPI Mode : DIO
I (57) boot: SPI Flash Size : 2MB
I (61) boot: Partition Table:
I (64) boot: ## Label Usage Type ST Offset Length
I (72) boot: 0 nvs WiFi data 01 02 00009000 00006000
I (79) boot: 1 phy_init RF data 01 01 0000f000 00001000
I (87) boot: 2 factory factory app 00 00 00010000 000f0000
I (94) boot: End of partition table
I (98) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1b3b8 (111544) map
0x40210010: _stext at ??:?
I (154) esp_image: segment 1: paddr=0x0002b3d0 vaddr=0x4022b3c8 size=0x05910 ( 22800) map
I (164) esp_image: segment 2: paddr=0x00030ce8 vaddr=0x3ffe8000 size=0x0002c ( 44) load
I (164) esp_image: segment 3: paddr=0x00030d1c vaddr=0x3ffe8030 size=0x00614 ( 1556) load
I (171) esp_image: segment 4: paddr=0x00031338 vaddr=0x40100024 size=0x0007c ( 124) load
I (180) esp_image: segment 5: paddr=0x000313bc vaddr=0x401000a0 size=0x04740 ( 18240) load
I (196) boot: Loaded app from partition at offset 0x10000
~/fpc/gitlab-cc/compiler/ppcrossxtensa -n @~/fpc/gitlab-cc/fpc.cfg -Tfreertos -Wpesp8266 -WP3.4 -Fl/home/christo/xtensa/examples/hello_world-esp8266/libs -Fl~/xtensa/xtensa-lx106-elf/xtensa-lx106-elf/lib -FD/home/christo/xtensa/xtensa-lx106-elf/bin -Ff/home/christo/xtensa/ESP8266_RTOS_SDK_v3.4 blink.pp
Free Pascal Compiler version 3.3.1 [2022/01/06] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling blink.pp
Assembling blink
Linking blink
esptool.py v2.4.0
69 lines compiled, 7.0 sec, 114206 bytes code, 44 bytes data
~/xtensa/ESP8266_RTOS_SDK_v3.4/components/esptool_py/esptool/esptool.py -c auto -p /dev/ttyUSB0 --baud 500000 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x10000 blink.bin
esptool.py v2.4.0
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
MAC: 84:f3:eb:76:de:3a
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 500000
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Compressed 157424 bytes to 101105...
Wrote 157424 bytes (101105 compressed) at 0x00010000 in 2.2 seconds (effective 570.0 kbit/s)...
Hash of data verified.
Leaving...
Hard resetting via RTS pin...
For my setup, I compile as follows:Code: [Select]~/fpc/gitlab-cc/compiler/ppcrossxtensa -n @~/fpc/gitlab-cc/fpc.cfg -Tfreertos -Wpesp8266 -WP3.4 -Fl/home/christo/xtensa/examples/hello_world-esp8266/libs -Fl~/xtensa/xtensa-lx106-elf/xtensa-lx106-elf/lib -FD/home/christo/xtensa/xtensa-lx106-elf/bin -Ff/home/christo/xtensa/ESP8266_RTOS_SDK_v3.4 blink.pp
Free Pascal Compiler version 3.3.1 [2022/01/06] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling blink.pp
Assembling blink
Linking blink
esptool.py v2.4.0
69 lines compiled, 7.0 sec, 114206 bytes code, 44 bytes data
~/eDevel/Embedded/fpc/source/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/fpc/source/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O3 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf-libs -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib -Fl~/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK/components/esp8266/lib -FD~/eDevel/Embedded/esp/xtensa-lx106-elf/bin -Ff$HOME/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK blink
Free Pascal Compiler version 3.3.1 [2022/01/05] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling blink.pas
Assembling blink
Linking blink
esptool.py v2.4.0
47 lines compiled, 2.0 sec, 114134 bytes code, 44 bytes data
(Note: I have to use $HOME for the framework option since it does not seem to recognize '~'.)For reference, find the generated binary attached.
Wrote 157472 bytes (101018 compressed) at 0x00010000 in 9.2 seconds (effective 136.6 kbit/s)...
Why are 69 lines compiled when there are only 47 in your Blink program?Well spotted! My original code contained a bunch of extra comments which I removed after pasting it to improve clarity of the code.
Your compiler options are quite a bit different than that shown in the instructions on the Wiki.
Incorporating some of your command-line options, this is what I get:Code: [Select]~/eDevel/Embedded/fpc/source/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/fpc/source/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O3 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf-libs -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib -Fl~/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK/components/esp8266/lib -FD~/eDevel/Embedded/esp/xtensa-lx106-elf/bin -Ff$HOME/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK blink
(Note: I have to use $HOME for the framework option since it does not seem to recognize '~'.)
Free Pascal Compiler version 3.3.1 [2022/01/05] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling blink.pas
Assembling blink
Linking blink
esptool.py v2.4.0
47 lines compiled, 2.0 sec, 114134 bytes code, 44 bytes data
My blink.bin is 48 bytes larger than yours.Code: [Select]Wrote 157472 bytes (101018 compressed) at 0x00010000 in 9.2 seconds (effective 136.6 kbit/s)...
And, along the same vein of success I've been having, it didn't work; no "hello", no flash, just the usual notice of "Loaded app from partition at offset 0x10000" and nothing after.
However...
I flashed your blink.bin ... and it worked!
For reference, find my generated blink.bin attached.
Could you perhaps compile the blink example with debugging information (dwarf 3, or -gw3), optimization level 1 (-O1) and attach or share the generated .elf file.(Just FYI: Using Kate, not Lazarus.)
~/eDevel/Embedded/fpc/source/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/fpc/source/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -gw3 -O1 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf-libs -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib -Fl$IDF_PATH/components/esp8266/lib blink
(IDF_PATH=$HOME/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK)A native FPC development branch ("main" in git; formerly "trunk" in svn) must be installed and working on the system and will be used to compile the xtensa cross compiler.
make FPC=~/fpcupdeluxe/fpc/bin/x86_64-linux/fpc CPU_TARGET=xtensa OS_TARGET=freertos SUBARCH=lx106 BINUTILSPREFIX=xtensa-lx106-elf- all -j
~/eDevel/Embedded/esp/8266/fpc/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/esp/8266/fpc/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O3 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf-libs -Fl$IDF_PATH/components/esp8266/lib -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib blink
Free Pascal Compiler version 3.3.1 [2022/01/09] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling blink.pas
Assembling blink
Linking blink
esptool.py v2.4.0
47 lines compiled, 2.8 sec, 114134 bytes code, 44 bytes data
While re-reading the instructions (https://wiki.freepascal.org/Xtensa), I see the following line which I must have glossed over before thinking I had read that a version of FPC greater than 3 was required (which I probably read somewhere else).QuoteA native FPC development branch ("main" in git; formerly "trunk" in svn) must be installed and working on the system and will be used to compile the xtensa cross compiler.
Is using a development branch version to compile ppcrossxtensa absolutely necessary? If so, how would I accomplish that?
Using fpcupdeluxe, I installed a "trunk" version of FPC into ~/fpcupdeluxe, but it did not add any path for that. Undoubtedly, the 'make' command as is would use /usr/bin/fpc which is v3.2.0. So I took a guess and recompiled ppcrossxtensa with:Code: [Select]make FPC=~/fpcupdeluxe/fpc/bin/x86_64-linux/fpc CPU_TARGET=xtensa OS_TARGET=freertos SUBARCH=lx106 BINUTILSPREFIX=xtensa-lx106-elf- all -j
Is the Makefile smart enough to use the newly installed trunk version's units, or would it use the units from my 3.2.0 version in /usr/lib64/fpc/3.2.0/?
ppcrossxtensa appears to be the trunk version:Code: [Select]~/eDevel/Embedded/esp/8266/fpc/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/esp/8266/fpc/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O3 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf-libs -Fl$IDF_PATH/components/esp8266/lib -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib blink
Free Pascal Compiler version 3.3.1 [2022/01/09] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling blink.pas
Assembling blink
Linking blink
esptool.py v2.4.0
47 lines compiled, 2.8 sec, 114134 bytes code, 44 bytes data
But, I don't know if the ppcrossxtensa might be a mish-mash of v3.3.1 and v3.2.0.
At any rate, rebuilding and re-flashing blink.bin did not provide success.
Could you perhaps compile the blink example with debugging information (dwarf 3, or -gw3), optimization level 1 (-O1) and attach or share the generated .elf file.(Just FYI: Using Kate, not Lazarus.)
The ELF file is too big to attach, so find it here:
https://www.dropbox.com/s/9w5zp4zbxu5m7fw/blink.elf.zip?dl=1 (https://www.dropbox.com/s/9w5zp4zbxu5m7fw/blink.elf.zip?dl=1)
(If there is an issue with the direct download, change dl=1 to dl=0)
While re-reading the instructions (https://wiki.freepascal.org/Xtensa), I see the following line which I must have glossed over before thinking I had read that a version of FPC greater than 3 was required (which I probably read somewhere else).QuoteA native FPC development branch ("main" in git; formerly "trunk" in svn) must be installed and working on the system and will be used to compile the xtensa cross compiler.
Is using a development branch version to compile ppcrossxtensa absolutely necessary? If so, how would I accomplish that?
Xtensa support is only available in the development branch (main). It probably would be included in fpc 3.4, but that is still a long way away.
I'm starting to suspect your problem is not really a compiler problem, but perhaps something odd with the SDK libraries you are using. I have tested your compiled blink, it doesn't appear to reach the main entry point of the FPC program. Will try to perform some debugging, but that is very flaky on the esp8266...
I used OpenOCD (https://github.com/sysprogs/esp8266-openocd) to debug your blink running on an esp8266. It was clear that the boot process got stuck in an exception after loading the application from flash, but before reaching the Pascal main.
[snip]
Since the executions does not reach FPC code, the problem is most probably in the bootloader code linked in from the SDK libraries. My guess is that the startup code does not properly initialize the CPU state.
I've set up the toolchain and SDK for the ESP32 also and tried with that. The 'hello world' example works, but the FPC 'hello' program does not. It seems unlikely there would be odd issues with both SDKs. But, I don't discount that possibility.
So, I re-installed the 8266 toolchain and SDK making sure to specify the SDK v3.4 branch as Andreas noted. After recompiling and flashing 'hello' and 'blink'; still no joy.That sucks, but must be fixable somehow...
My reference to the bootloader code is not quite accurate. The problem occurs after the bootloader jumps into the application image, so it is the startup code of the application that generates the exception, not the bootloader itself.I used OpenOCD (https://github.com/sysprogs/esp8266-openocd) to debug your blink running on an esp8266. It was clear that the boot process got stuck in an exception after loading the application from flash, but before reaching the Pascal main.
[snip]
Since the executions does not reach FPC code, the problem is most probably in the bootloader code linked in from the SDK libraries. My guess is that the startup code does not properly initialize the CPU state.
Thank you for taking the time to do that.
There are a couple things I do not understand about this:
1. Why does the 'hello world' example work but a FPC program does not with the very same bootloader?
2. Since I did not share my bootloader image, you must have used your own. So, wouldn't that mean the issue is also present in yours as well? Or, am I missing something?
If you can zip and share the SDK library folder with the .a, .ld and sdkconfig files you used to link your fpc example, I can compare that against my copies. Also relink an example against your libraries to see if the issue is repeatable on a different machine.
If you can zip and share the SDK library folder with the .a, .ld and sdkconfig files you used to link your fpc example, I can compare that against my copies. Also relink an example against your libraries to see if the issue is repeatable on a different machine.
I am unsure what exactly you mean by, "SDK library folder." I would think you mean the 'xtensa-lx106-elf-libs' folder that I created according to the instructions, but that has no 'sdkconfig' file. I can certainly copy sdkconfig to that dir before I zip it.
Regarding relinking an example, would you like the .bin, .o, and .elf (w/ or without debug info?) files? And, shall I do hello.pas since it is simpler?
~/fpc/gitlab-cc/compiler/ppcrossxtensa -iWD
3.3.1 2022/01/10
~/xtensa/xtensa-lx106-elf/bin/xtensa-lx106-elf-ld -v
GNU ld (crosstool-NG esp-2020r3-49-gd5524c1) 2.31.1
#hello> ~/eDevel/Embedded/esp/8266/fpc/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/esp/8266/fpc/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O1 -gw3 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf-libs -Fl$IDF_PATH/components/esp8266/lib -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib hello
Free Pascal Compiler version 3.3.1 [2022/01/13] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling hello.pas
Assembling hello
Linking hello
esptool.py v2.4.0
5 lines compiled, 2.7 sec, 105266 bytes code, 68 bytes data
#hello2> ~/eDevel/Embedded/esp/8266/fpc/compiler/ppcrossxtensa -Fu~/eDevel/Embedded/esp/8266/fpc/rtl/units/xtensa-freertos/ -Tfreertos -XPxtensa-lx106-elf- -O1 -Wpesp8266 -WP3.4 -Fl~/eDevel/Embedded/esp/fpc-esp8266-idf-3.4/libs -Fl~/eDevel/Embedded/esp/xtensa-lx106-elf/xtensa-lx106-elf/lib -gw3 hello
Free Pascal Compiler version 3.3.1 [2022/01/13] for xtensa
Copyright (c) 1993-2021 by Florian Klaempfl and others
Target OS: FreeRTOS
Compiling hello.pas
Assembling hello
Linking hello
esptool.py v2.4.0
5 lines compiled, 2.0 sec, 111562 bytes code, 68 bytes data
(I had to remove the framework option to get it to link; otherwise it complained about not finding linker script file esp8266.peripherals.ld)#> 8266/fpc/compiler/ppcrossxtensa -iWD
3.3.1 2022/01/13
#> xtensa-lx106-elf/bin/xtensa-lx106-elf-ld -v
GNU ld (crosstool-NG esp-2020r3-49-gd5524c1) 2.31.1
Well ... I found something that works*. Use Debian (or probably any Debian-based distro).I'm using a Debian derivative (Linux Mint)...
* At least I think it worked. Is it expected to see "_haltproc called, exit code: 0" on the monitor after "Hello world" is written?Yes, that is correct. Your simple hello program calls writeln, then exits. The default RTL action when your Pascal program exits main is to write the exit code (0 = no error). I am glad you finally got some output!
I tried a "live" Debian ISO image after trying a "live" Fedora image with no success.No idea. Just as I am none the wiser after trying to debug your executables.
Now the question is:
Why does it work on Debian 11.2.0 but won't work on Fedora 35 or openSUSE Leap 15.3?
user@linux-desktop:~/deb/esp/hello> readelf -l hello.elf
Elf file type is EXEC (Executable file)
Entry point 0x40212c5c
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x3ffe8000 0x3ffe8000 0x00634 0x01dc0 RW 0x1000
LOAD 0x002000 0x40100000 0x40100000 0x04783 0x04990 RWE 0x1000
LOAD 0x007010 0x40210010 0x40210010 0x1f388 0x1f388 RWE 0x1000
Section to Segment mapping:
Segment Sections...
00 .data .dram0.data .dram0.bss
01 .iram0.vectors .iram0.text .iram0.bss
02 .flash.text .flash.rodata
user@linux-desktop:~/eDevel/Embedded/esp/hello> readelf -l hello.elf
Elf file type is EXEC (Executable file)
Entry point 0x40212fa4
There are 4 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x001000 0x3ffe8000 0x3ffe8000 0x00634 0x01dc0 RW 0x1000
LOAD 0x002000 0x40100000 0x40100000 0x047a3 0x049b0 RWE 0x1000
LOAD 0x007010 0x40210010 0x40210010 0x1f22c 0x1f22c RWE 0x1000
NOTE 0x002000 0x40100000 0x40100000 0x00024 0x00024 R 0x4
Section to Segment mapping:
Segment Sections...
00 .data .dram0.data .dram0.bss
01 .note.gnu.build-id .iram0.vectors .iram0.text .iram0.bss
02 .flash.text .flash.rodata
03 .note.gnu.build-id
hello friend, i did on windows using latest fpcupdeluxe, open blink sample from ccrause github, i got following wrong ppu error, how to eliminate this problem?
thanks ccrause for your help, but it still got error result. i try open another sample.At least you have progressed to a new error :).
at which folder of this fpc.cfg must be change? i already to include that containing folder via project option but no luck :)
the folder no exists -> cross\bin\xtensa-freertos\esp-idf-4.3.2/ .
i surrender :D, c++ is more easy :DDo you mean C++ is easier to program in, or that using the native esp-idf build environment is easier to use? I guess it is the latter case, else you wouldn't have used LAMW for the Android app?
Hello friend, i go this message on my newly updated ubuntu, on ubuntu 18 libgc 2.6 cannot be installed so i upgraded my linux and got this message:It is possible that some of the required python packages were not installed or at an older version, so it may update on first compile. Do you see the message one every compile?
refreshing outdated venv, if you see this on every compile then create an issue on https://github.com/michael-ring/espsdk4fpc/issues
env. ubuntu 20, pip already install but cannot detect.
Thank you.
Hello friend, i go this message on my newly updated ubuntu, on ubuntu 18 libgc 2.6 cannot be installed so i upgraded my linux and got this message:It is possible that some of the required python packages were not installed or at an older version, so it may update on first compile. Do you see the message one every compile?
refreshing outdated venv, if you see this on every compile then create an issue on https://github.com/michael-ring/espsdk4fpc/issues
env. ubuntu 20, pip already install but cannot detect.
Thank you.
Also can you copy the whole message, including the python/pip related output?
Did you select trunk for the FPC version on the Basic tab of fpcupdeluxe? Xtensa-freertos is only supported in trunk (also called main).
Makefile:215: *** The Makefile doesn't support target xtensa-freertos, please run fpcmake first. Stop.
Did you select trunk for the FPC version on the Basic tab of fpcupdeluxe? Xtensa-freertos is only supported in trunk (also called main).
Makefile:215: *** The Makefile doesn't support target xtensa-freertos, please run fpcmake first. Stop.
already succed, but after i powering off my cpu, lazarus wont open anymore :). Thank you for your assistance, i give up.Sorry to hear about your problems with Lazarus, I know it is frustrating when things don't work. Fpcupdeluxe is an actively maintained project and has a dedicated thread (https://forum.lazarus.freepascal.org/index.php?topic=34645.new;topicseen#new) for discussing problems. You are welcome to post your Lazarus startup problem there (with details on what options you selected in fpcupdeluxe), I'm certain someone will be able to help.
You can also use the issues from GitHub.already succed, but after i powering off my cpu, lazarus wont open anymore :). Thank you for your assistance, i give up.Sorry to hear about your problems with Lazarus, I know it is frustrating when things don't work. Fpcupdeluxe is an actively maintained project and has a dedicated thread (https://forum.lazarus.freepascal.org/index.php?topic=34645.new;topicseen#new) for discussing problems. You are welcome to post your Lazarus startup problem there (with details on what options you selected in fpcupdeluxe), I'm certain someone will be able to help.
already succed, but after i powering off my cpu, lazarus wont open anymore :). Thank you for your assistance, i give up.Sorry to hear about your problems with Lazarus, I know it is frustrating when things don't work. Fpcupdeluxe is an actively maintained project and has a dedicated thread (https://forum.lazarus.freepascal.org/index.php?topic=34645.new;topicseen#new) for discussing problems. You are welcome to post your Lazarus startup problem there (with details on what options you selected in fpcupdeluxe), I'm certain someone will be able to help.
I want to know what linux do you used by the way? Could you explain your detail env on linux, may be mirroring your env, help me out this problem :DI run Linux Mint Mate 20.2. I don't install FPC or Lazarus via the package manager, but have several different versions of both that I compiled from source - this obviously requires a working binary FPC compiler to get going initially. While I can give more information on my setup, it is specific to my computer and would be difficult to adapt to a generic form. In general I followed the Linux installation guides for FPC (https://wiki.freepascal.org/Installing_the_Free_Pascal_Compiler#Linux) and Lazarus (https://wiki.freepascal.org/Installing_Lazarus_on_Linux) to get going initially. Things got a little bit more complicated when I started playing around with cross compilers for embedded targets (because of the different units per subarch).
I know the problem already if you use ubuntu 20(focal fossa), after you build and assign component your lazarus not work anymore, but it has different story if we build on ubuntu 18, all work ok, but no libgc2.65, installed, those lib are my recent problem on ubuntu 18 for extensa.I don't understand, libgc is a garbage collector for C/C++, this should not be a requirement for building Lazarus? Which widget set are you compiling for (GTK2, QT...)? This I think should be discussed under the Lazarus IDE board. There are many Linux users using Lazarus, getting Lazarus working on Linux should not be difficult once the required library dependencies are installed.
Hi
Interesting thread, currently I do not have a "free space" for any project in this direction however based on my curiosity, how to use the i2c protocol, does the freertos library already have features to allow i2c communication with extrenal devices (like oled dsplay)?
If I try to develop something for esp8266 then for sure would use fpcupdeluxe under Win10, however so far I've not tried xtensa+freertos yet.. so don't know what surprises are waiting for meUnfortunately xtensa on Windows via fpcupdeluxe is not yet supported. One can of course do a manual setup (https://wiki.freepascal.org/Xtensa) on Windows, but it is a little bit involved.
Thank you for info. According to fpcupdeluxe I see there options to check for xtensa and freertos, so I understand that despite I'm able to check them for installation I would not be able to compile program writen for xtensa (to put it another way-it is not as simply as for example, writing for Raspberry Pi under Windows), right ?
It is because there isn't yet a Windows snapshot, see list of available platform snapshots here: https://github.com/michael-ring/espsdk4fpc/releases/tag/v1.1.0-4
One can package the xtensa bintools and re-use the compiled libraries, but automatically sorting out the python dependencies to run the python tools such as esptool is a bit tricky.