WiFiNINA_Generic Library for WiFiNINA modules to support Teensy and more boards

I will give that a try, currently I am using pin31, and the traces are fine on the scope. I see 4 bytes reply with Chip select going low, 15usecs later 4 sets of 8 clocks, the response of MOSI is 0xC1, 0X41, 0x01, 0xDD on the MISO I see 0x7A, 0xE5, 0xD5, 0xCB on MISO, CS is raised high.
The ESP32 then sets busy, and 300uSec later I get 2 more clock pulses and 0xFF , 0xFF on MOSI, and 0xEF, 0x00 on MISO
As I said, nothing else is on the board except the Teensy and the module.
Hopefully my airlift module will arrive today, and I tempted to go back to the breadboard and test that, but I suspect I will get the same result.
I have been fighting this for about a week now.
This is the debug I get which seems to indicate that a reply is being received.
Used/default SPI pinout:
MOSI:11
MISO:12
SCK:13
SS:10
SPIWIFI_SS:31
SLAVESELECT:31
SLAVE_READY:23
SLAVERESET:26
SLAVEGPIO0:30
[C:\Users\georg\Documents\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::207]-W-Err cmd received

[C:\Users\georg\Documents\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::299]-W-Reply error
[C:\Users\georg\Documents\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::299]-I-A0,0
Communication with WiFi module failed!
 
Another way to do is to design with standard/stable ESP32 running as main processor, with WiFi and sensors and Teensy 4.0 as calculating/GUI co-processor. Then ESP32 communicates with and send necessary sensors' data to Teensy 4.0 via a serial bus for processing. Graphics intensive displaying/calculating functions can be handled by Teensy.

Going with this approach, you don't need to change much design of software as well as hardware. Using native ESP32 WiFi is much simpler, proven and more reliable than using WiFiNINA.
 
I will wait until I receive my airlift ESP32 Fadafruit breakout (there where no native featherboards left in stock), and reproduce it working with a teensy 3, and then see if I can get it to work on Teensy 4. I still think it is a firmware issue on the ESP32.
Would you have time to port the Firmware updater to work with Teensy?, then I would more control and have a reliable base of firmware to work against.
The utility won't connect to the ESp32 bootloader, but Serial passthrough works fine, but I don't have complete confidence in the firmware I am loading.
After that I will probably admit defeat and split the application as you suggest.
Most frustrating it should work.
 
Hi, just registered as I'm having very similar issues to @gredpath (although with a use case that isn't as important).

I'm using a Teensy 4.0 and trying to communicate with an Adafruit Huzzah32 ESP32 Breakout board (https://learn.adafruit.com/huzzah32-esp32-breakout-board?view=all), which I think is basically the same as the Airlift board just with more of the pins broken out.

I've been able to build the Adafruit Nina FW (https://github.com/adafruit/nina-fw) myself to generate a bin file and upload it to the ESP32. I've modified it slightly to use the standard ESP32 SPI3 pins listed here: https://docs.espressif.com/projects...pherals/spi_slave.html#gpio-matrix-and-io-mux

So pinout on the ESP32:
CS: 5
CK: 18
MOSI: 23
MISO: 19
READY: 33

And connected it to the SPI and digital pins on the Teensy 4.0 as follows:
CS: 10
SCK: 13
MOSI: 11
MISO: 12
READY: 14
RESET: 15
GPIO: 9

I'm getting the same errors with the reply error.

Attaching a cheap scope, it looks like I'm getting data on MISO at the same time as MOSI commands sent from the Teensy. I'm also not sure if the busy/ready line is meant to be high or low when the Teensy is transmitting or when the ESP32 is transmitting.

Here's a couple of screengrabs of what I think is the request for connection status from the Teensy (including data on the MISO line which I though shouldn't be there?) and then the unknown response from the ESP32.
Screen Shot 2020-04-28 at 12.20.43.png
Screen Shot 2020-04-28 at 12.23.26.png

It feels like I'm doing something fundamentally wrong but not sure what to try next.
 
Some progress, it seems that the module is still in boot mode. I changed the code to read from the ESP32 serial port so I could get some diagnostics.
The module seems to be being reset as part of the WiFi.status() command
I have attached the debug version of Scan Networks, I have set a buffer size for the serial port 256 characters, and cleared the buffer with flush(0 command before running WiFi.status();
Used/default SPI pinout:
MOSI:11
MISO:12
SCK:13
SS:10
SPIWIFI_SS:31
SLAVESELECT:31
SLAVE_READY:23
SLAVERESET:26
SLAVEGPIO0:30
[C:\Users\georg\Documents\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::207]-W-Err cmd received

[C:\Users\georg\Documents\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::299]-W-Reply error
[C:\Users\georg\Documents\Arduino\libraries\WiFiNINA_Generic-master\src\utility\spi_drv.cpp::299]-I-A0,0
Communication with WiFi module failed!
ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x33 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0018,len:4
load:0x3fff001c,len:832
ho 0 tail 12 room 4
load:0x40078000,len:9764
load:0x40080400,len:5700
entry 0x4008069c
 

Attachments

  • ScanNetworks.ino
    4.9 KB · Views: 67
David, I think you are pretty much at the exact same point as myself, it is good to have the confirmation that I am not the only one having the issue.
I see that my Adafruit Airlift is in the post on the way to me, so hopefully tomorrow I will test on a breadboard using a Teensy 3 as a first step, then test on a breadboard with a teensy 4 using the same pins.
I will let you know how I get on.
For me the main reason for this approach is that it comes loaded with tested firmware, so I can remove that from the equation, although I have followed their pinout and loaded their 1.4 & 1.6 images to my module.
 
David, I found that I have used Pin14 on board for MOSI on my board instead of Pin 13. When I changed to the correct pin, I now get intermittent communication to the ESP32, so it may be worth double checking your pinout.
Still don't understand why communication is not reliable, it is the only device on the bus, and the bus is only 7cm long, so it shouldn't be a problem.
 
I'm a bit confused by that - do you mean the Teensy pins? I thought MOSI was on pin 11 (not 13 or 14), which is also what you have listed above?

The MOSI output mostly seems right, in that first screenshot I get 0xEE 0x20 0x00 0xEE which seems like a well formed command for getting the connection status (according to these definitions https://github.com/khoih-prog/WiFiNINA_Generic/blob/master/src/utility/wifi_spi.h). What I'm not sure about is if there should be any data on MISO at that point, and whether the output on MOSI should be when the busy/ready line is high or low (in that screenshot the CS line goes low and then the Teensy seems to wait for busy/ready to go high and then output data on MOSI, but at the same time data is sent back on MISO).
 
@gredpath

I can confirm that the Slave select is not shared.

This can not be totally correct as Teensy or other boards could use it internally. I happens with ESP32 SPI bus conflict as default ESP32 SPI_SS has been used for SPIFFS/Flash/EEPROM. Using it (SS pin 5) creates sporadic hangs to the Ethernet shields and moving it away solve the problem (I tested OK using pin 13, but any another free pin will be OK if you try and be sure no problem). You also have to modify SPI driver if still have problem with pin assignment not as intended.

Would you have time to port the Firmware updater to work with Teensy?

Will have a look at it later. Just wake up after a sleepless night, sorry.

@dav1d

Similar answer to

So pinout on the ESP32:
CS: 5
CK: 18
MOSI: 23
MISO: 19
READY: 33
And connected it to the SPI and digital pins on the Teensy 4.0 as follows:
CS: 10
SCK: 13
MOSI: 11
MISO: 12
READY: 14
RESET: 15
GPIO: 9

as in

I can confirm that the Slave select is not shared.

Just try to move ESP32 CS from pin 5 and Teenst 4.0 CS from 10 to test. You also have to update WiFiNINA_Pinout_generic.h. to match. I don't know if it's OK but quite easy to try.

Also have a quick look at

WiFiNINA_Generic Issue: To support B302 <--> W102

NINA B302 as nRF52840 <--> WiFiNINA W102

NINA W102 with Ethernet
 
Some more to add

80452474-5a80a700-88f4-11ea-96fc-bf508d78873f.png

To be sure SS is not use internally, just run some basic code (not your SPI-slave code, but with all possible SPI-related functions such as SPIFFS, Flash, EEPROM-simulated, etc.), then use oscilloscope/Rigol SPI-analyzer to check SS (as well as MOSI, MISO, etc) to see if it's pulsing, and signaling that SS pins is used somewhere internally.
 
I have moved from 31 to 10, I have used 10 to drive the display (currently not plugged in) and it works rock solid, running for days.
I had made a mistake in that I had wired MOSI to pin 14 of the ESP and it should have been pin 13.
I am now back to where I was 2 weeks ago in that it is very unreliable ( with either Chip select). I had a brief high when I changed first changed the pin wiring when it all worked.
Now it works less than 10% of the time. On the scope the SPI bus is running at the correct speed.
On the same board when I connect the display the display runs reliably at 16MHz.
I tried dropping the SPI speed to 1MHz, but no difference.
Hopefully I will get the airlift tomorrow, and I will test it with both a Teensy 3 and Teensy 4, first on a breadboard.
Many thanks for your help
 
Hope to hear your good news tomorrow.

On the same board when I connect the display the display runs reliably at 16MHz.

IMHO, this can't prove that your SPI bus is running perfectly w/o conflict, as some small errors can't kill it. Screen display noises will be refreshed out before we noted. But this can't be the case for sensitive SPI-slave devices (network, SPIFFS, etc.), as just one erroneous bit can kill / stop it from working normally.
 
@gredpath, I'd be interested to see if swapping out your Teensy 4 for a Teensy 3 fixed it, the more I've read about Teensy 4 SPI comms the more I wonder whether there's a bug in that somewhere.
https://forum.pjrc.com/threads/5935...h-2-42-quot-Oled-and-u8g2-or-Adafruit-Library
https://forum.pjrc.com/threads/60195-T4-SPI-mode0-transmit-bug
https://forum.pjrc.com/threads/59906-SPI-MOSI-pulled-low-too-late-on-Teensy-4-0

I need to have a look at if the bugs have been fixed and whether I'm using the latest SPI Teensy libraries (I'm using PlatformIO so need to check it's using the latest).

I don't have another suitable controller to try, but am tempted to look at buying something else.
 
I've got it working! After almost a week of persevering with it!

Turns out it was an issue with SPI communication on the Teensy 4, that'll teach me for assuming standard comms on relatively new hardware will be working perfectly.

Basically, make sure you're using the latest code from the SPI repository here:
https://github.com/PaulStoffregen/SPI

I don't think the updates have made it in to Teensyduino (or the frameworks that PlatformIO uses if you're developing in that like me). I think the fix may have been this one:
https://github.com/PaulStoffregen/SPI/commit/fc9159a68189e5113f6996012091c61cf8652988

I'm also using the Adafruit NINA firmware compiled myself with a slight modification to which SPI pins it uses on the ESP32 (to use the standard VSPI/SPI3 pins described in the ESP-IDF documentation). Let me know if I can help with getting that working gredpath as I think you were having issues with that (although I'm on MacOS if that makes any difference).
 
David,

It's so great that you get it working now after finding out the SPI code issues.

I'm also using the Adafruit NINA firmware compiled myself with a slight modification to which SPI pins it uses on the ESP32 (to use the standard VSPI/SPI3 pins described in the ESP-IDF documentation).

Please also share your experience how to do this, as well as the pinouts you're modifying and using.
 
Compiling Adafruit NINA-W102 firmware for an ESP32:
(Note that it's a fork of the Arduino firmware, this all may work with that as well)

Clone/download this repo:
https://github.com/adafruit/nina-fw
The instructions are basically in the readme in that repo.

At the time of writing it's designed to work with the ESP-IDF v3.3.1, which has instructions of how to set that up here:
https://docs.espressif.com/projects/esp-idf/en/v3.3.1/get-started/index.html#setup-toolchain

I'm using a Adafruit HUZZAH32 ESP32 Breakout Board which has all the ESP32 pins available, so it seemed to make sense to use the standard SPI pins (which the Adafruit and Arduino versions of the firmware don't seem to do). I changed the pins that the ESP32 uses for SPI communication to those specified as VSPI/SPI3 in the ESP-IDF documentation here:
https://docs.espressif.com/projects...pherals/spi_slave.html#gpio-matrix-and-io-mux

The pins are:
CS: 5
MOSI: 23
MISO: 19
SCK: 18
BUSY: 33

So the line at the bottom of SPIS.cpp (https://github.com/adafruit/nina-fw/blob/master/arduino/libraries/SPIS/src/SPIS.cpp#L116) is now:
Code:
SPISClass SPIS(VSPI_HOST, 1, 23, 19, 18, 5, 33);

I used 'make menuconfig' (which is a tool that edits the sdkconfig file) to enable bootloader logging and console UART output, which ended up setting these options in sdkconfig:
CONFIG_LOG_BOOTLOADER_LEVEL_INFO=y
CONFIG_LOG_BOOTLOADER_LEVEL=3
CONFIG_CONSOLE_UART_DEFAULT=y
CONFIG_CONSOLE_UART_BAUDRATE=115200

Then run 'make firmware' to build. I uploaded it with a FTDI serial cable using the instructions for esptool.py described here:
https://learn.adafruit.com/upgradin...ernal-esp32#burning-nina-fw-with-esptool-3-24
 
Hopefully the problem is now solved, and I can confirm that the ESp32 works.
Using your library, and the Adafruit Airlift WiFI, I have proven communication between a Teensy 4 and a breakout. All the demos are working.
I used standard SPI bus and CS as 10, Busy on 9 and RST on 8.
I believe that the problem with my custom board is that I used a ACT buffer on MISO (5V levels) whereas I should have used a AC part (3.3 Volt supply and CMOS levels). This probably explains the intermittent behaviour of the connection.
For reference the firmware on the Adafruit is 1.2.2 which may cause some stability problems, but these should be resolved by updating to later firmware.
I have ordered some of the 3.3V buffer parts to test, and I will update this post accordingly.
Thanks for you assistance.
I would also like to make a shout out to Saleae who have provided me with a 16 channel logic analyser to support our regulatory testing.
 
ESP32 NINA Firmware is broken after 1.3.0

I continued to test, and upgraded the firmware on the ESP32 on the Adafruit airlift, and presented the exact same behaviour as the ESP32 on my board.
Thankfully I had purchased 2 boards, so I read the image from the second board using the command
python esptool.py --port COM62 --baud 115200 read_flash 0 0x200000 NINA_W102-1.2.2.bin
I then loaded this to the first airlift board and this worked.
I then loaded it to my custom board, and it worked also.
It seems that something is broken on the images including and after 1.4.0.
I would up load the file, but the rules don't seem to allow uploading binary files.
 
The Arduino/ublox firmware uses pin GPIO12 for MOSI whereas the Adafruit uses GPIO14, personally I think that UBlox is better as GPIO 13&14 default to the JTAG interface for the ESP32.
So the files don't load to the airlift without cutting tracks. Ineed to get the idf working so I can change pin assignments.
I have struggled with the IDF, mainly because the version that you build using the instructions uses cmake, whereas all the distributed source files use make. Is there an easy way to use make with the current build tools?.
Are such things better done using eclipse?
I freely admit that I am not a great programmer, I usually hammer my problems to death, and resolve them that way.
 
Did you check David's solution and how-to in David's #41 ?

I freely admit that I am not a great programmer, I usually hammer my problems to death, and resolve them that way.

Me too, not only you in the club.

I have struggled with the IDF, mainly because the version that you build using the instructions uses cmake, whereas all the distributed source files use make. Is there an easy way to use make with the current build tools?.
Are such things better done using eclipse?

I guess we have to use the most popular tools, Arduino IDE or Platform.io, so that it's much easier for other people to use. Those people, with much more experienced and are using specialized tools, already know how to use and fix the code / tools.

I still think you already solved the WiFiNINA issue already and don't understand what is the current problem now you're facing. I also don't have the same hardware to know and understand. Sorry can't help anything here.
 
Dav1d I am now reading your advice, which I am following to build a correct image. I am stumped with a make query, it complains about a colon in the path, I am using windows to build, and I tried various workarounds, what is the best way to get make to work?
 
I downloaded the most recent SPI library, checked with 1.2.2 and it was fine.
I used menuconfig and changed the settings as per your recommendations.
I then did a build but the linker failed

C:\esp\nina-fw-master>idf.py build
Checking Python dependencies...
Python requirements from C:\esp\requirements.txt are satisfied.
Executing action: all (aliases: build)
Running ninja in directory c:\esp\nina-fw-master\build
Executing "ninja all"...
[0/1] Re-running CMake...
-- mconf-idf version mconf-v4.6.0.0-idf-20190628-win32
-- Project version: v4.0-dirty
-- Building ESP-IDF components for target esp32
-- Could NOT find Perl (missing: PERL_EXECUTABLE)
-- Adding linker script C:/esp/nina-fw-master/build/esp-idf/esp32/esp32_out.ld
-- Adding linker script C:/esp/components/esp32/ld/esp32.project.ld.in
-- Adding linker script C:/esp/components/esp32/ld/esp32.peripherals.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
-- Components: app_trace app_update asio bootloader bootloader_support bt coap console cxx driver efuse esp-tls esp32 esp_adc_cal esp_common esp_eth esp_event esp_gdbstub esp_http_client esp_http_server esp_https_ota esp_https_server esp_local_ctrl esp_ringbuf esp_rom esp_websocket_client esp_wifi espcoredump esptool_py expat fatfs freemodbus freertos heap idf_test jsmn json libsodium log lwip mbedtls mdns mqtt newlib nghttp nvs_flash openssl partition_table protobuf-c protocomm pthread sdmmc soc spi_flash spiffs tcp_transport tcpip_adapter ulp unity vfs wear_levelling wifi_provisioning wpa_supplicant xtensa
-- Component paths: C:/esp/components/app_trace C:/esp/components/app_update C:/esp/components/asio C:/esp/components/bootloader C:/esp/components/bootloader_support C:/esp/components/bt C:/esp/components/coap C:/esp/components/console C:/esp/components/cxx C:/esp/components/driver C:/esp/components/efuse C:/esp/components/esp-tls C:/esp/components/esp32 C:/esp/components/esp_adc_cal C:/esp/components/esp_common C:/esp/components/esp_eth C:/esp/components/esp_event C:/esp/components/esp_gdbstub C:/esp/components/esp_http_client C:/esp/components/esp_http_server C:/esp/components/esp_https_ota C:/esp/components/esp_https_server C:/esp/components/esp_local_ctrl C:/esp/components/esp_ringbuf C:/esp/components/esp_rom C:/esp/components/esp_websocket_client C:/esp/components/esp_wifi C:/esp/components/espcoredump C:/esp/components/esptool_py C:/esp/components/expat C:/esp/components/fatfs C:/esp/components/freemodbus C:/esp/components/freertos C:/esp/components/heap C:/esp/components/idf_test C:/esp/components/jsmn C:/esp/components/json C:/esp/components/libsodium C:/esp/components/log C:/esp/components/lwip C:/esp/components/mbedtls C:/esp/components/mdns C:/esp/components/mqtt C:/esp/components/newlib C:/esp/components/nghttp C:/esp/components/nvs_flash C:/esp/components/openssl C:/esp/components/partition_table C:/esp/components/protobuf-c C:/esp/components/protocomm C:/esp/components/pthread C:/esp/components/sdmmc C:/esp/components/soc C:/esp/components/spi_flash C:/esp/components/spiffs C:/esp/components/tcp_transport C:/esp/components/tcpip_adapter C:/esp/components/ulp C:/esp/components/unity C:/esp/components/vfs C:/esp/components/wear_levelling C:/esp/components/wifi_provisioning C:/esp/components/wpa_supplicant C:/esp/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: C:/esp/nina-fw-master/build
[408/838] Performing configure step for 'bootloader'
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.23.0.windows.1")
-- mconf-idf version mconf-v4.6.0.0-idf-20190628-win32
-- The C compiler identification is GNU 8.2.0
-- The CXX compiler identification is GNU 8.2.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/Users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
-- Check for working C compiler: C:/Users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
-- Check for working C compiler: C:/Users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: C:/Users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe
-- Check for working CXX compiler: C:/Users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Project version: v4.0-dirty
-- Building ESP-IDF components for target esp32
-- Adding linker script C:/esp/components/esp32/ld/esp32.peripherals.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld
-- Adding linker script C:/esp/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld
-- Adding linker script C:/esp/components/bootloader/subproject/main/esp32.bootloader.ld
-- Adding linker script C:/esp/components/bootloader/subproject/main/esp32.bootloader.rom.ld
-- Components: bootloader bootloader_support efuse esp32 esp_common esp_rom esptool_py log main micro-ecc partition_table soc spi_flash xtensa
-- Component paths: C:/esp/components/bootloader C:/esp/components/bootloader_support C:/esp/components/efuse C:/esp/components/esp32 C:/esp/components/esp_common C:/esp/components/esp_rom C:/esp/components/esptool_py C:/esp/components/log C:/esp/components/bootloader/subproject/main C:/esp/components/bootloader/subproject/components/micro-ecc C:/esp/components/partition_table C:/esp/components/soc C:/esp/components/spi_flash C:/esp/components/xtensa
-- Configuring done
-- Generating done
-- Build files have been written to: C:/esp/nina-fw-master/build/bootloader
[512/838] Performing build step for 'bootloader'
[1/62] Generating project_elf_src.c
[2/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_periph.c.obj
[3/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_wdt.c.obj
[4/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/sdio_slave_periph.c.obj
[5/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/cpu_util.c.obj
[6/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/sdmmc_periph.c.obj
[7/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/gpio_periph.c.obj
[8/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_pm.c.obj
[9/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_time.c.obj
[10/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_clk_init.c.obj
[11/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_init.c.obj
[12/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/memory_layout_utils.c.obj
[13/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/spi_periph.c.obj
[14/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/lldesc.c.obj
[15/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_clk.c.obj
[16/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/rtc_sleep.c.obj
[17/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/esp32/soc_memory_layout.c.obj
[18/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/soc_include_legacy_warn.c.obj
[19/62] Building C object esp-idf/xtensa/CMakeFiles/__idf_xtensa.dir/eri.c.obj
[20/62] Building C object CMakeFiles/bootloader.elf.dir/project_elf_src.c.obj
[21/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/hal/spi_slave_hal.c.obj
[22/62] Building ASM object esp-idf/xtensa/CMakeFiles/__idf_xtensa.dir/debug_helpers_asm.S.obj
[23/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/hal/spi_flash_hal.c.obj
[24/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/hal/spi_hal_iram.c.obj
[25/62] Building C object esp-idf/xtensa/CMakeFiles/__idf_xtensa.dir/trax.c.obj
[26/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/hal/spi_hal.c.obj
[27/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/hal/spi_slave_hal_iram.c.obj
[28/62] Building C object esp-idf/xtensa/CMakeFiles/__idf_xtensa.dir/debug_helpers.c.obj
[29/62] Building C object esp-idf/log/CMakeFiles/__idf_log.dir/log.c.obj
[30/62] Building C object esp-idf/spi_flash/CMakeFiles/__idf_spi_flash.dir/spi_flash_rom_patch.c.obj
[31/62] Building C object esp-idf/soc/CMakeFiles/__idf_soc.dir/src/hal/spi_flash_hal_iram.c.obj
[32/62] Building C object esp-idf/efuse/CMakeFiles/__idf_efuse.dir/esp32/esp_efuse_table.c.obj
[33/62] Building C object esp-idf/efuse/CMakeFiles/__idf_efuse.dir/src/esp_efuse_api.c.obj
[34/62] Building C object esp-idf/efuse/CMakeFiles/__idf_efuse.dir/src/esp_efuse_fields.c.obj
[35/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_flash_config.c.obj
[36/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_common.c.obj[37/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_flash.c.obj
[38/62] Building C object esp-idf/micro-ecc/CMakeFiles/__idf_micro-ecc.dir/micro-ecc/uECC.c.obj
[39/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_clock.c.obj
[40/62] Building C object esp-idf/efuse/CMakeFiles/__idf_efuse.dir/src/esp_efuse_utility.c.obj
[41/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/flash_encrypt.c.obj
[42/62] Linking C static library esp-idf\log\liblog.a
[43/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/flash_partitions.c.obj
[44/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_random.c.obj[45/62] Building C object esp-idf/main/CMakeFiles/__idf_main.dir/bootloader_start.c.obj
[46/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/esp32/bootloader_sha.c.obj
[47/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_utility.c.obj
[48/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/esp_image_format.c.obj
[49/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/esp32/secure_boot_signatures.c.obj
[50/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/flash_qio_mode.c.obj
[51/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/esp32/secure_boot.c.obj[52/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/esp32/flash_encrypt.c.obj
[53/62] Linking C static library esp-idf\xtensa\libxtensa.a
[54/62] Building C object esp-idf/bootloader_support/CMakeFiles/__idf_bootloader_support.dir/src/bootloader_init.c.obj
[55/62] Linking C static library esp-idf\soc\libsoc.a
[56/62] Linking C static library esp-idf\micro-ecc\libmicro-ecc.a
[57/62] Linking C static library esp-idf\bootloader_support\libbootloader_support.a
[58/62] Linking C static library esp-idf\efuse\libefuse.a
[59/62] Linking C static library esp-idf\spi_flash\libspi_flash.a
[60/62] Linking C static library esp-idf\main\libmain.a
[61/62] Linking C executable bootloader.elf
[62/62] Generating binary image from built executable
esptool.py v2.8
Generated C:/esp/nina-fw-master/build/bootloader/bootloader.bin
[837/838] Linking CXX executable nina-fw-master.elf
FAILED: nina-fw-master.elf
cmd.exe /C "cd . && C:\Users\georg\.espressif\tools\xtensa-esp32-elf\esp-2019r2-8.2.0\xtensa-esp32-elf\bin\xtensa-esp32-elf-g++.exe -mlongcalls -Wno-frame-address -nostdlib @CMakeFiles\nina-fw-master.elf.rsp -o nina-fw-master.elf && cd ."
c:/users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: esp-idf/esp32/libesp32.a(cpu_start.c.obj):(.literal.main_task+0x18): undefined reference to `app_main'
c:/users/georg/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.2.0/../../../../xtensa-esp32-elf/bin/ld.exe: esp-idf/esp32/libesp32.a(cpu_start.c.obj): in function `main_task':
C:/esp/components/esp32/cpu_start.c:540: undefined reference to `app_main'
collect2.exe: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
 
Sorry I should have said that I used the standard adafruit 1.6.0 binary as couldn't build a new one.
 
Back
Top