Add a specific bin file for the E32 Gateway

[bbqkees]

The default board profile in the bin file from the release page is 'Custom'.
This is fine for the S32 Gateway as it is the same pinout. However, the E32 is different.
When a user flashes a Gateway via USB, or in some rare cases the upload via the web to a newer version resets stuff, the board profile is set again to 'Custom', which means no EMS bus and no Ethernet on the E32 until you login via WiFi to the AP and set the board profile to E32.

I get a ton of emails that after flashing the E32 is dead or defective, even though it is mentioned several times in the docs you need to set the board profile back to E32. A flashing LED but no EMS and no Ethernet confuses a lot of people.
It is also an inconvenience that flashing an E32 is not setting it to the correct 'factory default', and you have to login to the AP and adjust settings until Ethernet comes back online. People expect to be able to use Ethernet right away.

As a solution can we add a E32 specific bin file to the releases page so this is properly set after a USB flash?

[proddy]

I'll need to try this out. When flashing on a E32 it should not change any of the settings, including the board profile, unless a factory reset is done. Are you saying flashing via the USB removes the settings?

[bbqkees]

If you flash via USB the flash is erased first so nothing is kept from previous installs.

Flashing via the web apparently also sometimes resets the board profile. It is not something I could really reproduce, but I hear it from customers every once in a while.

[proddy]

I upload via the usb all the time using the esptool and it never erases the flash & settings. Is that using the ESP Flasher executable?

[bbqkees]

Yes indeed. It automatically erases flash before it loads the new firmware.

Everyone that needs to update to 3.5.0 from any version <October 22 will have to use the USB method because of the new partitioning.

[proddy]

ok, got it. We need to change the Flasher .exe to not erase the flash settings and we should be ok. That partition hasn't changed. @MichaelDvP is that possible?

[bbqkees]

Perhaps a checkmark 'erase flash first' or something would make the app more versatile.

[MichaelDvP]

The tasmota flasher have 320k SPIFFS, repartitioning will also affect the data partition and data aren't readable anymore.
I think compile a E32 bin is much easier, especially if we compile for C3, S2, and special version for Lolin_C3_mini_V1, which needs different wifi init and use standard led. A compile -D BOARD_E32 in an extra env not much work and can use the right boardprofile. This will load the board also if someone click factory reset or reset via button.

[bbqkees]

Ok then we might as well also create one for the S32 for completeness.

[MichaelDvP]

Added the E32 to my md5 branch. Changes are in this commit, Binaries here.

Is S32 dfferent from default?

[bbqkees]

No the S32 is the same as the current default 'Custom' profile, however, it says 'Custom' instead of 'S32'.
Choosing 'Custom' also exposes the textboxes to change the GPIO pins, which should be hidden for the S32 to prevent user errors.

[proddy]

I think the best option is to detect the presence of an ethernet module and default the board profile to E32 otherwise S32. I tried this before but now with the latest ESP-IDF 4.4.2 it's maybe easier to query

[MichaelDvP]

I needed this for the loader #608, An easy way is in (modifed type of board_profile):
bool System::load_board_profile(std::vector<int8_t> & data, String & board_profile) {
the default to:

    } else {
        // unknown, use defaults and return false
        if (ETH.begin(1, 16, 23, 18, ETH_PHY_LAN8720)) {
            data = {2, 4, 5, 17, 33, PHY_type::PHY_TYPE_LAN8720, 16, 1, 0}; // BBQKees Gateway E32
            board_profile = "E32";
        } else {
            data = {2, 18, 23, 5, 0, PHY_type::PHY_TYPE_NONE, 0, 0, 0}; // BBQKees Gateway S32
            board_profile = "S32";
        }
        return false;
    }

This shows after factory reset: [emsesp] No board profile found. Re-setting to E32 or S32 depending on board.

[proddy]

nice, if that works reliably then lets use that. I'll do some testing over the weekend. I was looking through the api to see if there was another way

[bbqkees]

Looks fine to me.

My plan once was to use 2 GPIO (12 and 14) to create a product ID.
On the latest S32 this is implemented on the board. (12 HIGH, 14 LOW).
For a next version of the E32 I wanted to use 12 HIGH, 14 HIGH.
It is not on the current E32.

[MichaelDvP]

I was looking through the api to see if there was another way

Sure you can check with api functions, the ESP.begin uses api functions and returns false if init failed. I don't know which one, but i think spi have to be configured and if spi communication fails it returned false. But it's only called one time on first start if filesystem is erased. Once set this case is never called again.

[proddy]

The tasmota flasher have 320k SPIFFS, repartitioning will also affect the data partition and data aren't readable anymore.
I think compile a E32 bin is much easier, especially if we compile for C3, S2, and special version for Lolin_C3_mini_V1, which needs different wifi init and use standard led. A compile -D BOARD_E32 in an extra env not much work and can use the right boardprofile. This will load the board also if someone click factory reset or reset via button.

@MichaelDvP do you think it's still worthwhile doing a -D BOARD_E32 ?

[MichaelDvP]

do you think it's still worthwhile doing a -D BOARD_E32 ?

No, now a blank ems-esp or after factory-reset the E32/S32 will load the right board profile, no need for extra settings.
Only difference for the user is: the log message on first start will show "No board profile found. Re-setting to E32" instead of "Load board profile E32"

[proddy]

Then Kees you may close this issue!