Problem building and function of SmartPower3 firmware

[cedel]

Hello, I tried to build and make SP3 firmware (to potentially fix some bugs) and ran into several issues. I may be doing something wrong, but at this moment don't see what that may be. Any help resolving this would be appreciated.

First of all, upgrading to standard provided precompiled v1.9 .img image works as expected and the device also works as expected.

1. I tried to follow the instructions at [https://wiki.odroid.com/accessory/power ... ource_code][/https://wiki.odroid.com/accessory/power ... ource_code] and ran into compile issue described in https://github.com/hardkernel/smartpower3/issues/10. After adding the header file, the compile and upload process seemed to work fine, but when the SP3 is reset after the process, the blue LED stays on and the power supply info on the main screen (top left corner) stays red and shows "0.0V 0.0A" even with regular power supply connected. Removing and restoring power does not help. Turning SP3 on/off via "ON/OFF/Menu/Cancel" button does not help either - the only difference being that when turned on, the power supply info changes color - "0.0" is grey and "V"/"A" are green and the blue LED is off. SP3 outputs no power. Channel switches seem to have no effect, but changing output power settings via encoder is possible. Serial seems to work, as well as connecting to WiFi, output logging (no changes in output values).

2. I tried different combination of libraries, different IDEs (Platformio for VSCode, Eclipse) on Fedora 36 x86_64 and different ways to flash the device:
2.a. - Updating TFT_eSPI to latest version the firmware compiles but does not work - the screen stays gray - no Hardkernel logo and no flashing blue LED.
2.b. - Trying to erase the ESP32 before flashing does not help either - uploading firmware and FS image works, but the SP3 seems to stay dead afterwards. The only solution being to flash the precompiled Hardkernel provided binary, which restores functionality.
2.c - I was not able to start debugging session neither via VSCode nor via Eclipse Platformio.

3. Tried to build and flash the original tagged v1.9 firmware from repo master branch to eliminate any changes I may have made to the code and that may have occured in master since release, with the same above results.

At this point I totally don't know what I may be doing wrong or if the problem is somewhere else. It seems to me that when flashing original firmware versus home-compiled firmware different ESP32 address ranges are erased and written to. Also, It's not clear to me how the precompiled .img is build/combines the firmware and fs. Somehow, I have a hunch that when I compile the firmware myself, something is missing or wrong /even though it compiles fine) - the blue LED not flashing seems to indicate that something is not working as it should and power checking does not start.

So in the end I have couple questions:
1. Anybody has any ideas what I may be doing wrong? Or what to check, how to proceed further?
2. Was anybody able to compile the firmware and after flashing the device worked as expected?
3. How is the manufacturer provided .img built?

[odroid]

We will try reproducing the issue since the latest firmware was built near one year ago.
Give us a few days.

[cedel]

@odroid Thank you very much - will be eagerly waiting for a reply.

Please let me know if you need any more info.

[roarking]

I experience the same problem: The firmware compiles and loads fine, but the device shows "00V 00A" in red in the upper left corner.

[roarking]

We could reproduce the issue with the latest framework and components.

The following list is the latest components and it didn't work properly.

Code: Select all

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (6.1.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
- framework-arduinoespressif32 @ 3.20007.0 (2.0.7)
- tool-esptoolpy @ 1.40500.0 (4.5.0)
- tool-mkfatfs @ 2.0.1
- tool-mklittlefs @ 1.203.210628 (2.3)
- tool-mkspiffs @ 2.230.0 (2.30)
- toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
Converting smartpower3.ino
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 39 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Wire @ 2.0.0
|-- STPD01
|   |-- Wire @ 2.0.0
|-- TFT_eSPI @ 2.3.67
|   |-- SPI @ 2.0.0
|   |-- SPIFFS @ 2.0.0
|   |   |-- FS @ 2.0.0
|   |-- FS @ 2.0.0
|-- ESP32Encoder @ 0.10.1
|-- PAC193x
|   |-- Wire @ 2.0.0
|-- FS @ 2.0.0
|-- SPIFFS @ 2.0.0
|   |-- FS @ 2.0.0
|-- ArduinoNvs @ 2.8
|-- WiFi @ 2.0.0
Building in debug mode

We could build a working firmware with the following old components nearly one year old.

Code: Select all

Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (6.1.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (cmsis-dap) External (cmsis-dap, esp-bridge, esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES:
- framework-arduinoespressif32 @ 3.20007.0 (2.0.7)
- tool-esptoolpy @ 1.40500.0 (4.5.0)
- tool-mkfatfs @ 2.0.1
- tool-mklittlefs @ 1.203.210628 (2.3)
- tool-mkspiffs @ 2.230.0 (2.30)
- toolchain-xtensa-esp32 @ 8.4.0+2021r2-patch5
Converting smartpower3.ino
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 39 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Wire @ 2.0.0
|-- STPD01
|   |-- Wire @ 2.0.0
|-- TFT_eSPI @ 2.3.67
|   |-- SPI @ 2.0.0
|   |-- SPIFFS @ 2.0.0
|   |   |-- FS @ 2.0.0
|   |-- FS @ 2.0.0
|-- ESP32Encoder @ 0.10.1
|-- PAC193x
|   |-- Wire @ 2.0.0
|-- FS @ 2.0.0
|-- SPIFFS @ 2.0.0
|   |-- FS @ 2.0.0
|-- ArduinoNvs @ 2.8
|-- WiFi @ 2.0.0
Building in debug mode

We will try finding which updates caused the issue.
It may take a couple of weeks.

[cedel]

@odroid

Thank you for the effort and info.

Are you sure the two console printouts are correct from the two runs? They are completely identical, probably the currently latest versions of everything. Knowing which versions compile and work OK would be useful in tracking down the change and problem.

I am also trying to debug the problem but so far no luck (but I am no expert).

I've tried downgrading the Espressif32 framework, no luck so far (but I haven't finished testing this yet - more tries to come).

So far it seems to me the main "loop()" in smarpower3.ino never finishes (does not loop at all) - it seems to block in reading info from PAC1933 over I2C in "_wire->requestFrom(I2C_ADDRESS, NBytes);".

Code: Select all

pseudo: (smartpower3.ino).loop() > mChs->sample(); > (meas_chan.cpp)) Meas_chans::sample() > PAC->Read(PAC1934_VBUS1_AVG_ADDR, 12, buffer); > (Microchip_PAC193x.cpp) Microchip_PAC193x::Read(uint8_t reg_address, int Nbytes, uint8_t *pBuffer) > _wire->requestFrom(I2C_ADDRESS, NBytes);

around line 88.

Hope we manage to solve the problem.

[cedel]

Code: Select all

platform = espressif32@3.5.0

seems to work, while

Code: Select all

platform = espressif32@4.0.0

and above does not.
Major library version changes between these two.

Code: Select all

Processing esp32dev (platform: espressif32@3.5.0; board: esp32dev; framework: arduino)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/espressif32/esp32dev.html
PLATFORM: Espressif 32 (3.5.0) > Espressif ESP32 Dev Module
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
DEBUG: Current (esp-prog) External (esp-prog, iot-bus-jtag, jlink, minimodule, olimex-arm-usb-ocd, olimex-arm-usb-ocd-h, olimex-arm-usb-tiny-h, olimex-jtag-tiny, tumpa)
PACKAGES: 
 - framework-arduinoespressif32 @ 3.10006.210326 (1.0.6) 
 - tool-esptoolpy @ 1.30100.210531 (3.1.0) 
 - tool-mkspiffs @ 2.230.0 (2.30) 
 - toolchain-xtensa32 @ 2.50200.97 (5.2.0)
Converting smartpower3.ino
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 33 compatible libraries
Scanning dependencies...
Dependency Graph
|-- Wire @ 1.0.1
|-- STPD01
|   |-- Wire @ 1.0.1
|-- TFT_eSPI @ 2.3.67
|   |-- SPI @ 1.0
|   |-- SPIFFS @ 1.0
|   |   |-- FS @ 1.0
|   |-- FS @ 1.0
|-- ESP32Encoder @ 0.5.1
|-- PAC193x
|   |-- Wire @ 1.0.1
|-- FS @ 1.0
|-- SPIFFS @ 1.0
|   |-- FS @ 1.0
|-- ArduinoNvs @ 2.8
|-- WiFi @ 1.0
Building in debug mode

[cedel]

As a temporary workaround, I've made PR https://github.com/hardkernel/smartpower3/pull/21 that fixes latest platform and library versions that I could find and that still work and compile to functional result.

[cedel]

And the winner seems to be Microchip with wrong usage of Wire/I2C in provided library. After changes in https://github.com/hardkernel/smartpower3/pull/22 (still WIP, looking into updates of all the libraries) the "no output" issue is gone.

A similar case and explanation (unrelated to Hardkernel) can be found at https://github.com/espressif/arduino-esp32/issues/6674 .

[odroid]

Thank you for sharing what you have found.
We will try those items including your pull-request.

[cedel]

Thank you for sharing what you have found.
We will try those items including your pull-request.

You are welcome.
Just give me a couple days, if you can, I am in the process of upgrading and testing the other libraries as well - and that might change the PR (and save you work of multiple testing). Will inform you when I think it's ready, if that's OK with you.

[cedel]

No problem. We can wait by early next week.
If you can't find a solution, we will assign an engineer to look into the issue seriously in the next week.

[smitna]

I must say some words to this project (firmware on GitHub)/this device:
Thanks to cedel a bug in the code was solved after one year of "stasis" in development of the firmware.
The device itself is (I think) EOL/in sale and still full of bugs in hard- and software.
That's not what I expect from hardkernel and I bought many good devices from this company in the past.