Wifi network missing after custom firmware update

[jazzbiddy]

Hi.

Running into some issues after uploading a custom firmware to the WVR Basic. I followed the steps in the readme here: https://github.com/marchingband/wvr#setting-up-for-arduino-ide-programming

I actually hadn't made any changes to the source yet. I was just making sure I could compile and upload, which I was. But after I clicked on the Boot button in the firmware section of the UI, and after it did the boot process - The WVR showed up in my wifi network list, but I was not able to connect with the default credentials, that I had been using prior to the update.

So I figured I'd just boot into recovery mode and get back up and running by holding D5 to ground when pressing reset on the WVR... but after doing that, the WVR was no longer visible in the wifi list at all, and now I can't seem to connect.

I'm thinking that my next best step is to use the FTDI setup to try to upload one of the WVR binaries, but wanted to check to see if there was anything else I should try.

Thanks

[marchingband]

Hi @jazzbiddy You're actually the second person to have this (very frustrating) experience. I'm sorry that happened! Yes you are correct, setting up FTDI is the next step, and something you will need in order to do hack with Arduino anyway. Once you have it set up, if you can share the error message that you get at boot, then I will be able to figure out what this bug is, and patch it. I have not been able to reproduce it at home.

[jazzbiddy]

I'm still getting things hooked up, but right now, prior to entering the FTDI bootloader mode, the WVR is just continuously rebooting with the following output...

14:56:02.842 -> Rebooting...
14:56:02.842 -> ets Jun  8 2016 00:22:57
14:56:02.842 -> 
14:56:02.842 -> rst:0xc (SW_CPU_RESET),boot:0x3f (SPI_FAST_FLASH_BOOT)
14:56:02.842 -> configsip: 0, SPIWP:0xee
14:56:02.842 -> clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
14:56:02.842 -> mode:DIO, clock div:1
14:56:02.842 -> load:0x3fff0018,len:4
14:56:02.842 -> load:0x3fff001c,len:1216
14:56:02.842 -> ho 0 tail 12 room 4
14:56:02.842 -> load:0x40078000,len:10944
14:56:02.842 -> load:0x40080400,len:6388
14:56:02.842 -> entry 0x400806b4
14:56:03.226 -> Total heap: 349128
14:56:03.226 -> Free heap: 322668
14:56:03.226 -> Total PSRAM: 0
14:56:03.226 -> Free PSRAM: 0
14:56:03.226 -> after begin, remaining: 260060, used:4294817868
14:56:03.274 -> Name: 8GTF4R
14:56:03.274 -> Type: MMC
14:56:03.274 -> Speed: 52 MHz
14:56:03.369 -> Size: 7456MB
14:56:03.369 -> CSD: ver=3, sector_size=512, capacity=15269888 read_bl_len=9
14:56:03.369 -> after emmc, remaining: 259108, used:952
14:56:03.369 -> Guru Meditation Error: Core  1 panic'ed (StoreProhibited). Exception was unhandled.
14:56:03.369 -> Core 1 register dump:
14:56:03.369 -> PC      : 0x400d1d90  PS      : 0x00060730  A0      : 0x800d678b  A1      : 0x3ffb1f10  
14:56:03.369 -> A2      : 0x00000000  A3      : 0x3ffc26fc  A4      : 0x00000000  A5      : 0x00000003  
14:56:03.369 -> A6      : 0x00000003  A7      : 0x00000000  A8      : 0x800d1d90  A9      : 0x3ffb1ef0  
14:56:03.369 -> A10     : 0x00000000  A11     : 0x65a268a3  A12     : 0x65a268a3  A13     : 0x3ffc746c  
14:56:03.369 -> A14     : 0x3ffb1eac  A15     : 0x3ffb1eac  SAR     : 0x00000004  EXCCAUSE: 0x0000001d  
14:56:03.369 -> EXCVADDR: 0x00000000  LBEG    : 0x400014fd  LEND    : 0x4000150d  LCOUNT  : 0xfffffffe  
14:56:03.369 -> 
14:56:03.369 -> ELF file SHA256: 0000000000000000
14:56:03.369 -> 
14:56:03.369 -> Backtrace: 0x400d1d90:0x3ffb1f10 0x400d6788:0x3ffb1f30 0x400d3b4d:0x3ffb1f70 0x400d1414:0x3ffb1f90 0x400e1fba:0x3ffb1fb0 0x4008ac8e:0x3ffb1fd0

Once I do the steps to get into bootloader mode, the serial monitor does print waiting for download so that's good.

Later tonight I'll try to figure out how to upload a working binary to it. I'm on windows right now, and the wvr.sh looks like it was meant for mac with the addresses of the usb, etc. I've got a mac so I might move to it to upload. I'll keep you posted.

[marchingband]

OK that indicates there is likely a mismatch between the config stored in the eMMC and the config that the firmware version requires. The fix in this scenario is an eMMC reset. To trigger this:

go into wvr/src/file_system.c on line 68 you will see char waver_tag[METADATA_TAG_LENGTH] = "wvr_magic_13"; increment this to "wvr_magic_14"

When you compile, flash, and run this firmware for the first time on your WVR, during the boot sequence, it will read the eMMC, notice that the tag is different, and therefor reset the eMMC, updating the stored tag, so it will not do it next time.

The last line of your error log is "Backtrace: ......" This is where you would be able to determine what line of your source code was running when the error was spotted. To decode it in an Arduino environment, you will need to install the plugin for Arduino IDE, and copy/paste this line into the plugin, and it will output the relevant stack trace. This is outlined in the getting started docs in the readme for this library.

If you can install the plugin, and get this backtrace decoded, please share the output, so I can confirm that this is the issue. This backtrace decoding process is a very normal part of ESP32 development using Arduino. It is strange, but it's just how it's done.

When you build a new firmware for the ESP32 in an Arduino environment, and you have FTDI setup, there are 2 ways to compile and flash the code. If you are using the Arduino IDE, then you can use the traditional "upload" button like usual. If (like me) you prefer to use VSCode, or some other IDE, then you can use the Arduino-CLI to compile, flash, set flags, etc. The bash script you mentioned helps when you are using the Arduino-CLI, but is not of any use without that installed. If you are just working inside the Arduino IDE, then stick to the "upload" button.

My preferred setup is to have VSCode, CoolTerm, Arduino IDE(just for the backtrace decoder), and a terminal (for the bash scripts) all open in different windows on my machine. The Arduino serial terminal also works, and the choice is totally up to the individual, there are many ways to work on the ESP32.

[jazzbiddy]

Here's that decoded backtrace.

file_system_init at C:\Users\jb\Documents\Arduino\libraries\WVR\src\file_system.c line 90
wvr_init(bool, bool) at C:\Users\jb\Documents\Arduino\libraries\WVR\src\wvr_0.3.cpp line 91
WVR::begin() at C:\Users\jb\Documents\Arduino\libraries\WVR\src\WVR.cpp line 16
setup() (C:\Users\jb\Downloads\WVR at 1)\WVR\examples\wvr_basic/wvr_basic.ino line 20
loopTask(void*) at C:\Users\jb\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.6\cores\esp32\main.cpp line 18
vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143

I incremented the value mentioned and uploaded from the arduino ide. It stopped the reboot cycle, but now just prints this and seems to do nothing.

05:49:52.940 -> ets Jun  8 2016 00:22:57
05:49:52.940 -> 
05:49:52.940 -> rst:0x1 (POWERON_RESET),boot:0x2f (UART_BOOT(UART0))

I've tried to print out the wifi status to serial and none of that is showing up in the serial monitor.

I did notice that in your binaries you provide a wvr_basic.ino.partitions.bin file. wondering if my upload isn't putting things in the right place. Anything special needed in the ide's board settings?

[marchingband]

(UART_BOOT(UART0)) is telling you that the ESP32 is in bootloader mode. It has 3 or 4 different kinds of bootloader modes, which are activated by holding certain pins low at boot. These are discussed at length in the ESP32 datasheet.

You likely still have D6 grounded at boot. If you release that from ground, it should follow the normal boot sequence.

wvr_basic.ino.partitions.bin has no use when uploading code over wifi, and I should remove it from that folder, it's just confusing, sorry about that.

[marchingband]

Your bug is not what I thought, it was not an eMMC version mismatch. You have selected the wrong board in Arduino, so it is not initializing the PSRAM. Please select "ESP32 Wrover Module" under tools->board

I will change this in the readme. I'm really sorry that step in the instructions wasn't clearer.

[jazzbiddy]

Bingo - we have a winner! It was that I had D6 still connected to ground.

No worries at all and thanks for the assistance. It was kind of my fault for mucking around - but now that I've got this sorted out, I can go in and see if can figure out how to remove the gap in the looped sample playback. that's a showstopper for my plans. I probably have a 1% chance of fixing it, but if I do, I'll put in a PR or let you know what I've found.

[marchingband]

Great! Thanks for getting on here and asking questions!

The issue with looping is that the whole audio engine works in chunks, so if the sample doesn't divide evenly into chunks of that size, there will be a gap. By the time the engine gets to the last chunk, it no longer holds the first chunk in RAM, and need the time to fetch it from eMMC. The whole timing of the engine is fixed around this chunk size.

In wav_player.c, the struct buf_t needs to have a special buffer to store the first chunk, maybe called buffer_head or something. Then the engine needs to detect the end of the last chunk, and switch over to the buffer_head, reset all the pointers and stuff, and then proceed as normal.

I am 95% done the last bit of hardware production, making the Thames pedals, then I will start coding all the feature requests :) In the meantime, have at it! And let me know if you have any questions!