Setting up Xtensa-FreeRTOS for ESP8266

[botster]

watch out for ModemManager.

My very first thought upon reading that was to try a different USB cable. Tried that. Tried a different USB port, too. No luck.

So, then I set ModemManager policy to STRICT and even stopped the service. Same error.

More to follow below.

[botster]

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:

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

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:

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

[ccrause]

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.

Yes, or alternatively check the esptool.py command generated when executing make flash inside the SDK example.  It is a useful troubleshooting exercise to verify that the SDK example works on the hardware.  This at least eliminates hardware and OS interference problems.

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:

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

Hash of data verified indicates successful upload.

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:

~/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).

Edit: fixed quoting

[botster]

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.

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):

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

hello.pp:

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

I don't know what else I can do.

[ccrause]

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 what the baud rate was for the SDK example, search for CONFIG_CONSOLE_UART_BAUDRATE in the file sdkconfig in the root of the SDK example project folder.  This is the baud rate which will be used for the normal program serial IO (except if the baud rate is programmatically changed, but then you should know what is going on  ).

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.

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):

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

hello.pp:

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

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.

I don't know what else I can do.

Try a slightly more busy version which keeps on pumping serial data:

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

1. program test;
2.  
3. // vTaskDelay is defined in libfreertos.a
4. // libfreertos.a is linked in automatically as part of the RTL
5. procedure vTaskDelay(xTicksToDelay: uint32); external;
6.  
7. begin
8.   repeat
9.     writeln('Hello');
10.     vTaskDelay(100); // the default tick duration is 10 ms, so this should delay for 1 s. This also keeps the watchdog happy.
11.   until false;
12. end.

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

[botster]

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

Okay, so I copied the bootloader and partition images from your snapshot to my test project directory and built the "busy" test program with (paths normalized to aid clarity):

~/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/

The result appears to be the same (ie. no "Hello"):

[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

Perhaps I did not follow your instructions correctly.

I tried rebuilding the SDK 'hello world' example using your sdkconfig (running Menuconfig only to change the usb path) and using the generated linker and image files. That did not produce success either.

The bootloader images between various builds differ. I suspect that is due to the differing sdkconfig settings (ie. baud rates, etc.).

At this point I have tried so many different things (including recompiling ppcrossxtensa) I am becoming lost in the various changes. I think I need to wipe everything and restart from scratch. But, that won't happen right away as I have other projects in need of attention.

[ccrause]

Alternatively try a simple blink, just to move away from baud rate issues and so forth.  Below an example which blinks an LED connected to GPIO2 (also used for TX1). On my NodeMCU devkit 1 board, this is connected to pin D4, in case your board doesn't have an installed LED on this output.  Of course if you have a different setup, change the LED constant below, or simply measure the pin voltage to confirm it is cycling high/low.

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

1. program blink;
2.  
3. type
4.   Tgpio_config = record
5.     pin_bit_mask: uint32;  // Pin mask of pins to configure
6.     mode: integer;         // 0 = disabled, 1 = input, 2 = output, 6 = output open drain
7.     pull_up_en: integer;   // 0 = disabled, 1 = enabled
8.     pull_down_en: integer; // 0 = disabled, 1 = enabled
9.     intr_type: integer;    // 0 = disabled, 1 = positive edge, 2 = negative edge, 3 = any edge, 4 = low level, 5 = high level
10.   end;
11.  
12. const
13.   // GPIO pin number for pin connected to LED
14.   LED = 2;  // NodeMCU LED on ESP-12E module
15.  
16. // Return value is error code, 0 = success
17. function gpio_config(constref gpio_cfg: Tgpio_config): integer; external;
18.  
19. // mode: GPIO_MODE_DISABLE = 0, GPIO_MODE_INPUT = 1, GPIO_MODE_OUTPUT = 2, GPIO_MODE_OUTPUT_OD = 6
20. function gpio_set_direction(gpio_num: integer; mode: integer): integer; external;
21.  
22. // level: Low = 0, High = 1
23. function gpio_set_level(gpio_num: integer; level: uint32): integer; external;
24.  
25. procedure vTaskDelay(xTicksToDelay: uint32); external;
26.  
27. var
28.   cfg: Tgpio_config;
29.  
30. begin
31.   cfg.pin_bit_mask := 1 shl ord(LED);
32.   cfg.mode := 1;
33.   cfg.pull_up_en := 0;
34.   cfg.pull_down_en := 0;
35.   cfg.intr_type := 0;
36.   gpio_config(cfg);
37.  
38.   gpio_set_direction(LED, 2);
39.   repeat
40.     writeln('.');
41.     gpio_set_level(LED, 0);
42.     vTaskDelay(100);
43.     writeln('*');
44.     gpio_set_level(LED, 1);
45.     vTaskDelay(100);
46.   until false;
47. end.
48.  

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
For reference, find the generated binary attached.
Flash blink.bin to controller:

Code: [Select]

~/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...
Edit: Note that I have previously flashed the bootloader and partition images for this SDK version, so this time round I only needed to flash the application.

Edit2: I forgot about the writeln statements!  The blinking LED is hopefully present to confirm successful upload.  Additionally one can check the serial output @ 115200 baud:

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

1. $<0x9c><0x9f>|<break>
2. <0x84>l<0xe0><<0x03><0x0c><0x04><0x04><0x8c><0x04>l<0xe4><0x04>c|<0x8f><0xc3><0x03><0xe4><0x13><0x9b>;<0x93>c<0x8c><0x04>c<0x84><0xfb>gn<0x9f>dog<0x9c><0xe3><0xe4><0x04>c<0x1c>8<0x84><0x87>lrd;lx<0xf3>o<0xe0><0x18><0x03><0x0c><0x04><0xc3><0x0c>d<0x0c><0x04><0x04><0x0c><0x04><0x0c>#<0x04>g<0xe3>|<0x02><0xe4><0x87>p<0xd8><0x04><0x0c>#<0x8c><0xf3>ng<0xef><break>
3. l<0x8c><0x8f>l <0x03><0x98><0x13><0x1b>g'l<0x8c>$`<0x03><0x0f><0x03>g{<0x8f><0x92><0x9b>o<0x0c><0x04><0x12><0xe3><0xdb> <0x03>`<0xf2>n<0x0c><0x04><0x04><0x9f><0xe0>c<0xc3>'$<0x8c><0x04><0x8c><0xf3>og<0xe7><break>
4. <0x0c><0xc7><0x07>l8<0xfb>o<0xe0><0x10><0x03><0x0c><0x04>;<0x84><0x9c><0xdc><0xe3><0xe0><0x0c><0x8e><0x04><0x0c>b<0x0c>'<0xe3>|<0x03><0x84><0x0c><0x8e>c<0x8c><0xfb>o'<0xe7><break>
5. l<0x84><0x0c>d`<0x02><0xd8><0x1b><0x12>'ol<0x84>l <0x03><0x07><0x03>n;<0x87><0x93><0xdb>g<0x04><0x0c>c<0xc4><0xc7><0x07>l`<0xf3>o<0x0c><0x04><0x0c><0x9e><0xe0>c<0x83>nl<0x84><0x0c><0x8c><0xfb>g'<0xe7><break>
6. <0x0c><0x8f><0x0e>dp<0xfb>g<0xe0><0x10><0x02><0x04><0x0c>s<0xc4><0x9c><0x9c><0xe3><0xe0><0x0c><0x8f><0x1c><0x80><0x04>c<0x0c>o<0xe2>|<0x03><0xec><0xec><0xc4><0x0c><0x8e>c<0x8c><0xfb>g'<0xe7><break>
7. l<0xc4><0x0c>d`<0x02><0x98><0x13><0x1b>g'<0x0c>l`<0x03><0x07><0x03>or<0xc7><0x9b><0x92>'<0x0c><0x0c><0x9b>l<0x9b>`<0x02><0x07>{<0x92><0x9b>o<0x0c><0x04><0x92>d<0xdb>`<0xa1><0xa3>+<0xda><0x9a><0x92>j%<0x81>(49) boot: ESP-IDF v3.4-43-ge9516e4c 2nd stage bootloader<0x1b>[0m
8. <0x1b>[0;32mI (49) boot: compile time 13:24:36<0x1b>[0m
9. <0x1b>[0;32mI (49) boot: SPI Speed      : 40MHz<0x1b>[0m
10. <0x1b>[0;32mI (53) boot: SPI Mode       : DIO<0x1b>[0m
11. <0x1b>[0;32mI (57) boot: SPI Flash Size : 2MB<0x1b>[0m
12. <0x1b>[0;32mI (61) boot: Partition Table:<0x1b>[0m
13. <0x1b>[0;32mI (64) boot: ## Label            Usage          Type ST Offset   Length<0x1b>[0m
14. <0x1b>[0;32mI (72) boot:  0 nvs              WiFi data        01 02 00009000 00006000<0x1b>[0m
15. <0x1b>[0;32mI (79) boot:  1 phy_init         RF data          01 01 0000f000 00001000<0x1b>[0m
16. <0x1b>[0;32mI (87) boot:  2 factory          factory app      00 00 00010000 000f0000<0x1b>[0m
17. <0x1b>[0;32mI (94) boot: End of partition table<0x1b>[0m
18. <0x1b>[0;32mI (98) esp_image: segment 0: paddr=0x00010010 vaddr=0x40210010 size=0x1be20 (114208) map<0x1b>[0m
19. <0x1b>[0;32mI (155) esp_image: segment 1: paddr=0x0002be38 vaddr=0x4022be30 size=0x05a6c ( 23148) map<0x1b>[0m
20. <0x1b>[0;32mI (165) esp_image: segment 2: paddr=0x000318ac vaddr=0x3ffe8000 size=0x0002c (    44) load<0x1b>[0m
21. <0x1b>[0;32mI (166) esp_image: segment 3: paddr=0x000318e0 vaddr=0x3ffe8030 size=0x00614 (  1556) load<0x1b>[0m
22. <0x1b>[0;32mI (173) esp_image: segment 4: paddr=0x00031efc vaddr=0x40100000 size=0x00080 (   128) load<0x1b>[0m
23. <0x1b>[0;32mI (182) esp_image: segment 5: paddr=0x00031f84 vaddr=0x40100080 size=0x04740 ( 18240) load<0x1b>[0m
24. <0x1b>[0;32mI (198) boot: Loaded app from partition at offset 0x10000<0x1b>[0m
25. <0x1b>[0;32mI (220) gpio: GPIO[2]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0 <0x1b>[0m
26. .
27. *
28. .
29. *
30. .
31. *

A * should be output when the pin is high and . when the pin is low.

[botster]

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

Why are 69 lines compiled when there are only 47 in your Blink program?

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

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.

[af0815]

Thanks for the blink sample. I am now able to run this sample with a windows system for cross compiling. The input from this thread was good for me.

[ccrause]

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.

I use several different folder structures for testing, hence the paths in my example will not necessarily match the wiki convention.  I have now added -WP3.4
to the wiki compile command line, since this option is becoming more important as more SDK versions are released.

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
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 '~'.)

I have also noticed the same - for some options the home folder shortcut on Linux is expanded, other options seem to use it literally.

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

There are a couple of things that can cause a difference in compiled size:

• options passed to fpc when compiling example program
• configuration used when building the SDK example libraries
• gcc compiler and bintools versions

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.

Hmm, lets not give up just yet, there must be a way  to figure this out. 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.  If using Lazarus remember to unselect the Display line numbers in run-time error backtraces -gl option.  When I have time I can poke around to try and figure out what is going on.

[botster]

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
(If there is an issue with the direct download, change dl=1 to dl=0)

Built with:

Code: [Select]

~/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)

[botster]

While re-reading the instructions, 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).

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.

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.

[ccrause]

While re-reading the instructions, 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).

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.

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.

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/?

The MakeFile used by FPC is designed to work inside the folder structure of FPC source. If you start make from the root of the trunk source folder, it will start by building a native compiler using the starting stable compiler, then use the trunk native compiler to compile the cross compiler.

The starting compiler make will use can be specified with the FPC variable.  In your example above it will use the fpcupdeluxe version of FPC, not the one installed in /user.  Also, fpcupdeluxe provides its own fpc.cfg that points to the appropriate compiled units.

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.

Nope, FPC checks compiled unit versions and would complain if it encounters a unit that was compiled with a different compiler version.

At any rate, rebuilding and re-flashing blink.bin did not provide success.

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

[af0815]

I have switch to the correct branch (3.4) in the development git of expressif, before i get this working in windows. After this i build the sample new and use this new generated libs and bins. After this, i could build a working sample with fpc (on windows), working on the esp8266. And i have used the newest cross-tools from expressif.

With the master branch of the git from expressif, it was not working. This was my fist mistake.

[ccrause]

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
(If there is an issue with the direct download, change dl=1 to dl=0)

I used 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.  Stepping through the startup code proceeded until it tries to execute the privileged RSIL instruction, which raises an exception.  Execution appears to be stuck inside the exception handler after this:

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

1. Temporary breakpoint 9, call_start_cpu (start_addr=<optimized out>) at /home/user/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK/components/esp8266/source/startup.c:154
2. 154     in /home/user/eDevel/Embedded/esp8266/ESP8266_RTOS_SDK/components/esp8266/source/startup.c
3. => 0x40213b3d <call_start_cpu+169>:     20 62 00        rsil    a2, 2
4.    0x40213b40 <call_start_cpu+172>:     11 8a f1        l32r    a1, 0x40210168 <_stext+344>
5. (gdb) si
6. xtensa_step: Timed out waiting for target to finish stepping.
7.  
8. Program stopped.
9. 0x40100070 in _KernelExceptionVector ()
10. => 0x40100070 <_KernelExceptionVector+28>:      00 00 00        ill
11. (gdb)

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.