No core dump partition found

[SV-Krishna]

Hello

Enjoying assembling this project, however I've come across a problem. Following upload and monitor in platformio, I get the following error. Do you know what might be the cause.

_ClipperDuet2N2k unknown

ets Jul 29 2019 12:21:46

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (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:0x3fff0030,len:1184 load:0x40078000,len:13192 load:0x40080400,len:3028 entry 0x400805e4 E (531) esp_core_dump_flash: No core �f�␋�partition found! E (531) esp_core_dump_flash: No core dump partition found! [ 40][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: offset NOT_FOUND [ 41][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: cal NOT_FOUND [ 45][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: threshold NOT_FOUND [ 54][E][Preferences.cpp:503] getBytesLength(): nvs_getblob len fail: shallo

[speters]

Hm. I have never run into this.

Did you try either adding a core dump partition (adding coredump, data, coredump,, 64K in partitions_custom.csv) or set a build flag to disable core dumps -DCONFIG_ESP_COREDUMP_ENABLE_TO_NONE ?

Greets from Hamburg, Germany.

[SV-Krishna]

Thanks, for the reply - strangely enough, I added this line

coredump, data, coredump,, 64K,

which has removed some of the errors, but leaves the following.....and greetings from Edinburgh

ClipperDuet2N2k unknown

ets Jul 29 2019 12:21:46

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (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:0x3fff0030,len:1184 load:0x40078000,len:13192 load:0x40080400,len:3028 entry 0x400805e4 [ 68][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: offset NOT_FOUND [ 69][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: cal NOT_FOUND [ 74][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: threshold NOT_FOUND [ 82][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: shallo

[speters]

Seems like your platform versions are quite old, which is why the NVRAM-functions aren't there.

I changed the platformio.ini to clearify the versions I used.

The espressif32 platform I tested on was 5.0.0 (6.5.0 build also works). The code still relies on older versions of AsyncTCP and ElegantOTA libs, which is now also specified.

[SV-Krishna]

Good morning

Thanks for the super prompt update!

I've replaced platformio.ini and uploaded. I get a very similar error. I've also tried using a different board (same model - DF Robot Firebeetle ESP32-E V1.0 - straight out of the box) just in case it might have been hardware related.

What else can I try?

ClipperDuet2N2k unknown

ets Jul 29 2019 12:21:46

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (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:0x3fff0030,len:1184 load:0x40078000,len:12784 load:0x40080400,len:3032 entry 0x400805e4 [ 14][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: offset NOT_FOUND [ 15][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: cal NOT_FOUND [ 19][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: threshold NOT_FOUND [ 28][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: shallo

[SV-Krishna]

Here's some additional build terminal output - if this helps?

Building in release mode Retrieving maximum program size .pio\build\esp32dev\firmware.elf Checking size .pio\build\esp32dev\firmware.elf Advanced Memory Usage is available via "PlatformIO Home > Project Inspect" RAM: [= ] 12.6% (used 41184 bytes from 327680 bytes) Flash: [==== ] 42.1% (used 855261 bytes from 2031616 bytes) Configuring upload protocol... AVAILABLE: cmsis-dap, esp-prog, espota, esptool, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa CURRENT: upload_protocol = esptool before_upload(["upload"], [".pio\build\esp32dev\firmware.bin"]) Looking for upload port... Auto-detected: COM7 Uploading .pio\build\esp32dev\firmware.bin esptool.py v3.3 Serial port COM7 Connecting.... Chip is ESP32-D0WD-V3 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 08:3a:8d:17:49:48 Uploading stub... Running stub...

[speters]

Sorry, I was thinking in the wrong way and thought you were running into compile-time errors.

This Preferences "errors" are signs that the controller has not yet been configured. See README.md: First start

But the output should not end with

[ 28][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: shallo

like you wrote (note the "shallo"). It should read "shallow_alarm" , followed by another complaint concerning "speed_alarm".

Your debug output somehow interferes with the normal serial operations. I wonder why your debug output concerning the preferences is printed after the "ClipperDuet2N2k unknown" message (which is meant to contain a git_describe-derived version number, seems not to run properly on Windows). The order in the sourcecode is different: first read preferences, then print version number.

Please also check your pin definitions. Your FireBeetle 2 ESP32-E board is a bit different to what I used.

[SV-Krishna]

No problem,

Following your message above I put the Duet in to config mode, ran through the parameter settings following the readme instructions.

Whilst in configuration mode I checked to see if a wireless access point had been created. None could be seen. I have the following lines in main.cpp

// define if OTA updates via WIFI should be enabled

define WITH_OTA

I then took the ESP32 out of the housing, connected to the PC running platformio, the terminal displays the same preference errors as before. If the config has been written to non-volatile memory, then should this not have resolved the issue?

Here's a photo of the board in its housing. Note that I'm pulling 12v from the NMEA 2000 network, stepping down to 5v.

The firebeetle does have different pin definitions and I have already updated these as follows:

define PIN_HTDATA GPIO_NUM_16 // HT1621 DATA is SPI MOSI on our ESP32 SPI Slave implementation

define PIN_HTDATAOUT GPIO_NUM_6 // unused, but must a usable pin for SPI MISO

define PIN_HTCLK GPIO_NUM_14 // HT1621 WR is SPI Clk on our ESP32 SPI Slave implementation

define PIN_HTCS GPIO_NUM_12 // HT1621 CS is SPI CS on our ESP32 SPI Slave implementation

The TX/RX GPIO pin definitions are the same.

On the git_describe point you mention I get this warning when compiling - as its just a warning I think little of it - but perhaps its relevant?

Generating partitions .pio\build\esp32dev\partitions.bin src/main.cpp:47:2: warning: #warning "no N2K_SOFTWARE_VERSION from git" [-Wcpp]

warning "no N2K_SOFTWARE_VERSION from git"

^~~ src/main.cpp:51:2: warning: #warning "no GIT_DESCRIBE from git" [-Wcpp]

warning "no GIT_DESCRIBE from git"

^~~

[SV-Krishna]

Hello again from a cold Edinburgh.

I think I am the problem here having read and reread your guide. Can you tell me the make and model of ESP32 board please and I will use that.

I would like to use a board that has the same pin assignments as you have in your code. Although I thought I had made the necessary changes in the code for the firebeetle, I now think this is incorrect.

My experience here is limited, so this is the best course to take.

Thanks in advance

[speters]

I used a "Lolin32 lite" board. You can see some photos in doc/. I chose it because it's cheap and low-profile and I had one lying around in my drawer. I wouldn't recommend it because it comes unshielded. A properly shielded module with U.FL antenna connector would be better suited.

A more elaborate solution would be to use the back of the front PCB and engrave or etch some suitable traces for the ESP32 module, the 3.3V power supply and the CAN transceiver and solder them on. As you can see in the pictures, I only scored a few traces for the CAN transceiver - I was too lazy to do it nicely.

You can also see that I upgraded the original linear 5V voltage regulator as I derived the power supply for the ESP32 board from it.

When assembling, be careful of the extension caps for the push button switches as the latter can be bent and damaged if not fitted correctly. I found it easiest to turn the front panel upside down, place the extensions in the recesses and then insert the board.

[SV-Krishna]

Hello again, held off responding until the Lolin32 lite board arrived and I'd added it in.

So here is where I am. Board added, wiring all updated and checked with multi meter for continuity.

Uploaded the project from Github, ensuring OTA updates enabled. Connected the Duet. Connected to NMEA2000 network. Started the Duet in Set Eng mode, a WiFi access point didn't appear. Proceeded anyway. Confirmed all config in Duet, exited config.

NMEA2000 network is running SailorHat ESP32. On that I can see that SignalK on my PI is transmitting PGNs (Date and Time) but non is being received.

Here is a picture of the DUET PCB, where you can see the relevant chips

Here's one of the connections from the Clipper PCB

and the last is the Lolin board with connections (there is a change in cable colours, continuity from the Duet PCB to the Lolin board has been tested)

The USB cable was added to see if I could capture any debug information. This is not normally there when testing. I'm really not sure where to go next - do you have any suggestions

[speters]

You should at least see the ESP32 sending PGN 60928 (ISO address claim) and PGN 126993 (heartbeat) to the NMEA2000 bus. This would also work if no ClipperDuet is connected.

With DEBUG defined, you get some logs to the serial (115200,8n1).

With DEBUG_COMMS defined, the ESP32 is printing to the serial console what it received via SPI from the HT1621 communications. This is helpful to check if your wiring to the PIC/LCD controller lines is correct.

You seem to have a 120Ohms termination resistor on the CAN transceiver board. Is your CAN bus correctly terminated (check if those pins are meant for jumpering to enable the termination)? Are you sure the CAN transceiver IC is a genuine 3.3V type? Maybe try some examples first to make sure your NMEA2k is up and running.

[SV-Krishna]

Hello again,

You seem to have a 120Ohms termination resistor on the CAN transceiver board. Is your CAN bus correctly terminated (check if those pins are meant for jumpering to enable the termination)?

I tested the NMEA 2000 network and realised that I needed to remove the 120 Ohms termination receiver from the CAN Transceiver Board. This brought the network resistance value to 60 Ohms.

With DEBUG_COMMS defined, the ESP32 is printing to the serial console what it received via SPI from the HT1621 communications. This is helpful to check if your wiring to the PIC/LCD controller lines is correct.

I enabled debug and and could see that the ESP had created PGN 60928 and PGN 126993. I could also see PGN 126992 which I believe has come from SignalK as a result of me setting up the Signal K to NMEA2000 plugin and configuring system time to be sent each second. Here is the debug information:

[    32][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: threshold NOT_FOUND
[    40][E][Preferences.cpp:503] getBytesLength(): nvs_get_blob len fail: shalloCAN device ready

ClipperDuet2N2k unknown

Start address claim for device 0
260 : Pri:6 PGN:60928 Source:32 Dest:255 Len:8 Data:D4,D4,7A,22,0,3C,E,C0
810 : Pri:2 PGN:126992 Source:15 Dest:255 Len:8 Data:FF,FF,1D,4D,30,DF,D5,1F

and here's the line with the heartbeat

7976 : Pri:7 PGN:126993 Source:15 Dest:255 Len:8 Data:60,EA,0,FF,FF,FF,FF,FF

Here's more output if it helps - ClipperDuetDebug_Comms.txt

I used a multimeter to check that there was continuity from each of the 4 pins on the DUET PCB to the respective pins on the ESP to rule out any wiring issues.

The Debug_Comms output didn't display anything other than these three PGNs.

So I think its safe to assume that the NMEA2000 network health is good and the CAN Transceiver is operating correctly.

When entering Set Eng on the clipper duet the ESP didn't establish a wireless access point.

Are you sure the CAN transceiver IC is a genuine 3.3V type?

Its a Waveshare CAN transceiver running at 3.3V and appears to send and receive data.

What do you think? To me its as though the ESP doesn't recognise that the DUET is there

[SV-Krishna]

Hello - great news,

The penny dropped. It was clear that the problem was with the cable used to send the signal between the Clipper Duet and the Lolin board. I'd used some spare CAT5 network cable. I took this back to basics and connected everything together with some Dupont wires and now it all works.

Not sure why CAT5 would be an issue - but thats not a concern.

Thanks for this project - can't wait to get off the test rig and running on the boat.