Artiphon

This thread is intended to gather the feedback of Orba tinkerers.

@BJG145 Here is a shot in the dark... I hunted through 0x8000000.bin and found an area that I believe might be where the constants are defined. I changed a value of 120 to 121 and 240 to 241. If you can upload this and then check the loop info maybe we'll have a hit?! It's a needle in a haystack but it's an educated guess. :)

This isn't very interesting, but just for completeness, it's the console log for the alternative "Commencing BLE serial pass-through with ESP32 in normal mode". These are probably just for debugging Bluetooth data.

...hmm, at first glance I'm not sure how useful this is going to be. While it's in that state it seems you can read/write any section of the 4MB Flash memory, but judging by this "partition table" in the console log the contents don't look very exciting. I was hoping to see an entry labelled: "Secret quantization parameters" or something. :-P

I (87) boot: SPI Flash Size : 4MB
I (91) boot: Partition Table:
I (95) boot: ## Label            Usage          Type ST Offset   Length
I (102) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (110) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (117) boot:  2 factory          factory app      00 00 00010000 00100000
I (125) boot: End of partition table

@BJG145 said: " I don't know if you might have a clearer idea what kind of differences there are...?"

Unfortunately, I don't. I can tell you that this .bin file is likely just a memory dump that can be downloaded/uploaded from/to the device. It definitely contains what I would consider compiled C code. Disassembling compiled C would be almost as cryptic as the bin itself. It might be best to hunt through the bin file looking for any bytes that hold the values 120, 240 or 240. It might be possible to zero in on where the default values are defined. Since this is C, there won't be any indication of variable names so we need to hunt by value rather than by name. There are likely numerous hits if you search for those bytes, but if we're lucky they might appear close together which would be an area of the code where all these variables get initialized. 

...referring back to the flash log, the three files that get sent to the Orba immediately after that point are delorean.bin, bootloader.bin and partitions_singleapp.bin. I think the last two seem to be standard filenames that crop with up with ESP32 programming, whereas delorean is the Orba's special one.

(Log file)

I've finally managed to get esptool.py to work.

I was convinced that the ESP32 would only respond if was in programming mode, but I couldn't figure out how to get it into that state.

Then I remembered the log from the good old B console command, "Commencing BLE serial pass-through with ESP32 in programming mode." (Attached)

Some of these commands just seem to put the Orba to sleep; no lights, no DFU mode, nothing. But it occurred to me that they might quietly have gone into programming mode. So I tried running one ofg the standard esptool.py commands, retrieving the MAC address, immediately after "B" in the console...never got this (or any other esptool commands) to work before, and bingo. :-)

Whether it's actually useful or not is another matter, but it's a new channel of communication with the Orba, and it explains why some of the console commands put it in a trance.

 The attached console log is "1" for looper info followed by "B" for "Commencing BLE serial pass-through with ESP32 in programming mode." I was wondering whether any of the values reported by that command might relate to the missing quantisation values like "quantStartSnapTicks".

It finishes up by waiting for a download; in other words, it wants some kind of file transfer, which we might be able to do with esptool if we can knew what it was after.  

There's documentation available on these files like  "partitions_singleapp.bin"; they're evidently part of the ESP32 programming environment, but that's getting a bit too deep for me.

https://esp32.com/viewtopic.php?t=2528

(...also been trying to use esptool.py to recreate this part of the log which talks about 4MB Flash memory, but drawn a blank on that as well...)

20 Jun 2022 9:29:59pm - esptool.py v2.8-dev

20 Jun 2022 9:29:59pm - Serial port \\.\COM12

20 Jun 2022 9:29:59pm - Chip is ESP32D0WDQ5 (revision 1)

20 Jun 2022 9:29:59pm - Features: WiFi, BT, Single Core, VRef calibration in efuse, Coding 

20 Jun 2022 9:29:59pm - Crystal is 40MHz

20 Jun 2022 9:29:59pm - MAC: 8c:aa:b5:9b:4c:10

20 Jun 2022 9:29:59pm - Configuring flash size...

20 Jun 2022 9:29:59pm - Auto-detected Flash size: 4MB

...I think I've now managed to compare the files in hex view, but there are changes all over the place.

Back to the drawing board...

Here's another set of three with an empty sequence which might be simpler.

1) Initial state, quantise on

2) Toggle off

3) Toggle back on

To recap, the DFU website lists four entries:

DFU: cfg=1, intf=0, alt=0, name="@Internal Flash 

DFU: cfg=1, intf=0, alt=1, name="@Option Bytes /0x1FFF0000/01*048 e"

DFU: cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FF07800/01*528e"

DFU: cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e"

The first one is 0x8000000.bin, the one we can edit to change console commands, though values remain obscure, and the file doesn't change when you do things like change quantise mode inthe console or record notes. In other words, it looks like it has the console program, but not the loop data.

The others only have a few bytes each; low-level processor management stuff. 

...but what about 0x20010000.bin...? That's the other slightly more substantial one that gets uploaded at the start of the flash-from-file process.

It doesn't appear in that web list, but I've found that you can still upload it from the Orba via a Windows command prompt via dfu-util. The flash log has:

dfu-util.exe -d 0483:df11 -a 0 -s 0x20010000:force -D  \0x20010000.bin

...where "D" means "Download", or "Send to Orba". But if you change that to "-U" for "Upload", you can grab it.

I just tried:

1) Upload it

2) Change quantisation mode from console

3) Upload a scond copy

4) Record some notes

5) Upload a third copy  

...and finally these files are changing. I can tell that much from the "Compare" plug-in in Notepad++

...but it's all garbage and weird characters. I'm sure this is the wrong view and I should be using a hex editor or something. (?)

Here's two versions of the file; the only thing I did deliberately was to toggle quantisation in the console, but more might have happened than that. @Subskybox I don't know if you might have a clearer idea what kind of differences there are...? Is there some other view or decoding that I should be using for these .bin files...?

1) Initial state

2) Toggle quantise

3) Record four lead notes

If you use the DFU website to upload 0x8000000.bin from the Orba, edit it, then download it again, you can change the console messages.

Unfortunately I still can't see how to change the values. 

I now think that in console mode we're probably talking to a program running on the STM32.

(...Orba needs a firmware reset after that "W" trick...)

The website above reveals four blocks of memory:

Your device has multiple DFU interfaces. Select one from the list below:

DFU: cfg=1, intf=0, alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg"

DFU: cfg=1, intf=0, alt=1, name="@Option Bytes /0x1FFF0000/01*048 e"

DFU: cfg=1, intf=0, alt=2, name="@OTP Memory /0x1FF07800/01*528e"

DFU: cfg=1, intf=0, alt=3, name="@Device Feature/0xFFFF0000/01*004 e"

1) 0x08000000 is the corresponding .bin file

2) The "Option bytes"

3) "OTP" is "one-time programmable"; I think we can ignore this, it's an inaccessible preset

4) Not sure, possibly 0x20010000.bin...?

I've been uploading these from the Orba, changing quant setting and uploading again, comparing the results, but nothing much yet. One of them seemed to reduce in size drastically at one point, need to revisit that, but I don't think these are what we want.

When I posted the teardown on this forum, @Tony made some notes about memory:

ESP32 module's internal memory comprises, according to the ESP32-SOLO-1 datasheet: 

448 KB of ROM for booting and core functions.

520 KB of on-chip SRAM for data and instructions.

8 KB of SRAM in RTC, which is called RTC FAST Memory and can be used for data storage; 8 KB of SRAM in RTC, which is called RTC SLOW Memory

1 Kbit of eFuse: 256 bits are used for the system (MAC address and chip configuration)

Winbond 25x40CL (not far from the AKM DAC) is a 4Mb (ie 512KB) serial flash memory.

https://www.digikey.co.uk/en/datasheets/winbond-electronics/winbond-electronics-w25x40cl_f-20140325

The "Winbond" chip might be where the action is, haven't found how to access that yet. There are console options like "W" which says: "Forcing RAM Write to flash" but then closes the connection. (?)