I've encountered an issue with the final batch module that didn't occur with the hand soldered test version: I wasn't able to boot from USB power. All my other modules work perfectly from my powered USB hub, this doesn't. It only has issues with a cold start: if I use a 12V supply when switching it on, I can remove the 12V supply after boot and also do reboots while only supplying USB power. The next cold boot from USB will fail again. The module keeps rebooting with a "brownout detector was triggered" message right after adding the SPIRAM pool: ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x1b (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:5328 ho 0 tail 12 room 4 load:0x40078000,len:11332 load:0x40080400,len:6204 entry 0x400806cc I (1053) psram: This chip is ESP32-D0WD I (1054) spiram: Found 64MBit SPI RAM device I (1054) spiram: SPI RAM mode: flash 40m sram 40m I (1057) spiram: PSRAM initialized, cache is in low/high (2-core) mode. I (1064) cpu_start: Pro cpu up. I (1068) cpu_start: Application information: I (1073) cpu_start: Project name: ovms3 I (1078) cpu_start: App version: 3.3.001-285-g601f2a70 I (1084) cpu_start: Compile time: Feb 19 2022 07:59:04 I (1090) cpu_start: ELF file SHA256: 09c85890b31e6080... I (1096) cpu_start: ESP-IDF: v3.3.4-848-g1ff5e24b1b I (1103) cpu_start: Starting app cpu, entry point is 0x400818d4 I (1094) cpu_start: App cpu up. I (1981) spiram: SPI SRAM memory test OK I (1981) heap_init: Initializing. RAM available for dynamic allocation: I (1981) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM I (1987) heap_init: At 3FFBF770 len 00020890 (130 KiB): DRAM I (1994) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (2000) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (2007) heap_init: At 4009CCFC len 00003304 (12 KiB): IRAM I (2013) cpu_start: Pro cpu start user code I (2018) spiram: Adding pool of 4096K of external SPI memory to heap allocator *Brownout detector was triggered* ets Jul 29 2019 12:21:46 rst:0xc (SW_CPU_RESET),boot:0x1b (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:5328 ho 0 tail 12 room 4 load:0x40078000,len:11332 load:0x40080400,len:6204 entry 0x400806cc I (1053) psram: This chip is ESP32-D0WD … Does the new mainboard draw a higher current? Or is the modem possibly configured differently from the test module causing an early high current consumption? Regards, Michael Am 22.02.22 um 19:35 schrieb Craig Leres:
I'd like to congratulate Mark and crew on the v3.3 hardware; I've been running with one new v3.3 ovms module and two new sim7600G modems for a few weeks without issue. While I still see the new modems connecting to 3G at times, it's really nice to have 4G capability well in advice of the retirement of 3G. (The updated v3 esp32 is also nice...)
Given that my frankenstein modules still go into "user interrupt" after so many hours of uptime, I think the best explanation is that it is due to differences in their sim7600A-H firmware. I'd offer to ship Mark one of mine for debugging if that would be at all useful given he is not located in north america. (And if there is someone in the US that would like to take a run at solving sim7600A issues, contact me offline.)
Craig _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26