PSRAM for hardware rev 4

[KlausMu]

Just as an idea: it seems that you can add PSRAM to every ESP32 wroom. You don't explicitely need an ESP32 wrover.
I found this idea here about the Cheap Yellow Display

I once ran OMOTE on such a "cheap yellow display" (ESP32-2432S028Rv1), just to see if it works.

Then I ordered a PSRAM for $2, soldered it and - it works. Didn't know that this is possible.

Maybe it is worth to add a SOIC8 footprint to hardware rev 4. The ESP32-PICO-D4 could be kept. PSRAM could even be optional. GPIO16 and GPIO17 are still free on the OMOTE, this is all you need.

I believe that the additional 4 MB RAM is not needed now. But if OMOTE should ever support web based configuration, I guess this will not be possible with the standard RAM of 320k, where most is already taken by WiFi, BLE and LVGL.

[CoretechR]

Interesting, I did not know that PSRAM could be added without sacrificing IO. I will have to look deeper into this but there seem to be some differences between the Wrover and Pico mappings. IO16 on the Pico-D4 is connected to the Flash Chip select:

[CoretechR]

Espressif suggests the SD3 pjn for PSRAM chip select, which could probably be freed, too. But another little problem, I just assembled the first Rev4 board today. 😅

[KlausMu]

Ok, too late 😁
It seems that WiFi and BLE both automatically use PSRAM if it is available.
And LVGL can be told to use PSRAM.
This really dramatically increases the available heap.
We can keep this in mind for future.

[vblimits]

is rev4 available anywhere? i was going to add PSRAM as i feel it will benefit this project greatly and i would like to build one.

[CoretechR]

It is assembled and working but I want to do some more testing first before releasing it to GitHub.
Sorry, but Rev4 does not include a footprint for external PSRAM as that topic came up after I ordered the PCB.
However, you could always edit the board files yourself if you want to use PSRAM.

[vblimits]

yes i know its not part of rev4 was going to add it rev 4 as i dont really see a point in doing that work to an already outdated board,
i dont see anything about rev 4 really what all did you add/change? is the foot print the same?
i am looking to also design a aluminum case but also dont want to put all that time in if the pcb is going to change.

[CoretechR]

I just created a branch for Rev4: https://github.com/CoretechR/OMOTE/tree/PCBRev4
This will be added to the main branch later, but you can check it out already.

[vblimits]

thank you, what version of KiCad are you using?

[CoretechR]

8.0.1

[JustMe-NL]

I just created a branch for Rev4: https://github.com/CoretechR/OMOTE/tree/PCBRev4 This will be added to the main branch later, but you can check it out already.

I loved the idea of the gauge so I ordered some and deadbugged one in one of my remotes which are rev3. I added the code and it worked quite well. But now main tries to init the battery gauge chip before the Wire lib is initialized, so you get some delay starting up because of the errors. If I move init_battery() to after init_gui(), the Wire is initialized (in tft_hal_esp32.cpp) and the errors are gone.

[CoretechR]

Great that you able to build this into rev 3! I am aware that the fuel gauge init depends on wire. It can only start working properly after the touch IC is initialised. But I did not notice errors or crashes because of this. Which ones did you get?

[KlausMu]

fuelGauge.begin(); retries the connection 3 times, with delay of 50 in between. Overall it takes 180 ms (I don't have a fuelGauge). That's indeed significantly.

What happens if you replace fuelGauge.begin(); with fuelGauge.setWirePort(Wire); as discussed here . It only takes 0 ms. Does it still work? My guess is yes, it still works, without changing the order of initialization.

We changed the order in the past, but sometimes it had side effects. @CoretechR should thoroughly check it if we did this. I think switching to fuelGauge.setWirePort(Wire); could be safer.

[JustMe-NL]

Well, I crawled my way out of another nice little rabbithole. Let me explain: I currently have three Omotes rev3 (minimum order by Jlcpcb was 5 so, why not?):

Omote A: modified with the APX reset chip - main use in the livingroom with multiple devices
Omote B: modified with the MAX17048G and 8 white LEDs on the keypad - used in the bedroom
Omote C: as of yet, still vanilla - so far unused

Adding the MAX17048G went perfect on Omote B so I wanted to add this to Omote A as well. After testing the wiring on the bench I added the chip to the PCB using CA glue. Reflashed the latest firmware from my private repository and ... I get kernel panics, why?

I use the same firmware on all remotes with the same platformio settings (side note: that means all my remotes have TFTRST set to 0 so the TFT library does not issue a softreset plus they all run at the maximum SPI speed of 80MHz without any problems whatsoever! Keep in mind that only Omote A has the APX reset chip!). But there are differences in how the Omotes operate, on the settingsgui I added, apart from the sensitivity slider, a toggle for the room in which the remote is used. I did this because the channelnumbers on the TV in the bedroom are different from the livingroom (don't ask, stupid digital cable provider won't let me change the numbers), plus in the bedroom there is only the TV to command.

So I reflashed the exact same firmware on Omote B and that worked fine. But then it must be my solderingskills or a malfunctioning chip (from AliExpress, so it is not unheard of). Ok, remove the max17048G and replace with another fresh chip. Power on and … panic. Unlikely that from 3 chips only the first worked so maybe because I skimped on the 100nF capacitor? Nope. not that either.

After fiddling with the code it is obvious this has everything to do with battery_hal_esp32: if I enable the init_battery_HAL routine, I have no problems but if I enable get_battery_status_HAL the systems crashes. Both fuelGauge.getVoltage and fuelGauge.getSOC cause problems. But fuelGauge.begin, which internally does communicate with the chip, works fine and returns true.

After adding monitor_filters = esp32_exception_decoder and build_type = debug to the platformio.ini I got a confirmation that it is the fuelGauge.getVoltage that causes the problem but wait … why is this a problem if fuelGauge.begin is not?

I had moved battery_init to after the init_IMU. But there is a significant difference between Omote A and B: Omote A has bluetooth enabled and B (because of the room setting) not. And before the Wire is initialized the Bluetooth keyboard is initialized and requests the batterystatus to show the real battery on the connected host. After changing init_keyboardBLE_HAL in keyboard_ble_hal_esp32 to report a dummy value for the battery, the panic is over.

But this also means that the fuelGauge.setWirePort(Wire) workaround is not an option. Maybe move the Wire init to init_hardware_general_HAL in hardware_general_hal_esp32, since the Wire is no longer exclusively used by the TFT, it does make more sense to move to a more general location.

Anyway, now I have this:
Omote A: modified with the MAX17048G and APX reset chip - main use in the livingroom with multiple devices
Omote B: modified with the MAX17048G and 8 white LEDs on the keypad - used in the bedroom
Omote C: as of yet, still vanilla - so far unused

TL;DR:
fuelGauge has problems if bluetooth keyboard is enabled because Wire is used without it being initialized and the intended function (showing the battery status on the connected host) does not work this way.

[KlausMu]

Ok, I see. Tricky. The IMU is also using I2C. Now we have three players.

Using the I2C bus without the tft chip being powered caused problems in the past. So you must have digitalWrite(LCD_EN, LOW); before using the bus.

But having digitalWrite(LCD_EN, LOW); and Wire.begin(SDA_GPIO, SCL_GPIO, 400000); in init_hardware_general_HAL() caused other problems, as you might remember: #70 (comment)

So if the fuelGauge is now using I2C, I think we have to move register_device_keyboard_ble(); after init_gui();.
Everything which is using I2C has to be after init_gui();. That's why init_IMU(); is so late.

Could you please test moving register_device_keyboard_ble(); right before init_IMU();?
Then we could keep the workaround with fuelGauge.setWirePort(Wire)

Otherwise we had to move both init_battery() and register_device_keyboard_ble(); after init_gui(); and could keep fuelGauge.begin();