Artiphon

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

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.  

Good news I re-read your DFU instructions and the Orba App found it in DFU mode.. I then re-flashed firmware, opened a serial connection and set quantize on. I played back many of the songs I'd previously recorded (some of them quite sloppy) and the all sound pretty decent! definitely tighter. Now you've got me hooked on exploring a bit more. I'd like to see if we can read/update some values in there. I can't seem to get it to do the ascii animation thing. I suspect you need a good terminal for that. I need to go back and re-read your posts on this now :)

Now I'm really excited. Chrome also has a Serial API. I predict we will be able to change values from the Editor in the future.. :)

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

No idea...but now that they finally seem to be in stock at Gear4Music, I've just re-ordered one...

(...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 notice that song files have quatizationMode and volume...Have you changed those while the hardware Quantization is on?"

I've tried the console commands for volume +/-, which work OK, but I haven't tried changing it with XML.

(I don't know if you've tried editing song files, but you'd probably need to create a copy of it rather than editing the original to get any result.)

I can't find the loop info parameters anywhere except in 0x8000000.bin, where they look like this:

   Looper Configuration:

   loopBarEndTolerance: %u

   beatLengthTicks: %u

   notesPerBar: %u

   quantMode: %u

   quantStartSnapTicks: %u

   quantBarEndSnapTicks: %u

   allowRecordingSilenceStart: %u

   allowRecordingSilenceEnd: %u

   thinnerMode: %u

   cc_error_limit: %lu

   pbend_error_limit: %lu

   ccA: %u

   ccB: %u

   ccC: %u

   thickenerMode: %u

   thickenerEmitPrd: %u

   thickenerMaxDt: %u

   noteStartWindow: %u

The Orba.exe app starts with:

quantStartSnapTiMZ

...as the first data, and that's about it.

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

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.

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. (?)

I've put together some notes on the flash-from-file log and distilled it to a list of file transfers.

 I think what happens is:

1) The App establishes opens communication with the STM32 and sends it:

a)  option_bytes.bin (a few bytes of low-level processor settings)

b)  0x20010000.bin (120KB, no text, name is memory target)

c)  0x8000000.bin (exactly 64KB, includes looper info text from console, name is memory target)

2) The App opens communication with the ESP32 and sends it:

a) 21_X0_CY8C_Touch_A0_2988ebe.cyacd, 19KB for the Cypress touch sensor, data block. Hex?

b) bootloader.bin, 25KB, bootloader messages text

c) partitions_singleapp.bin, 3KB, no text

d) delorean.bin, 680KB, Bluetooth error messages

I'd previously thought that the STM32 didn't do all that much and the ESP32 did most of the heavy lifting, but I'm now starting to wonder if actually the STM32 does most of it.

When I posted the teardown on the Facebook page, someone wrote:

**************************************************************************

...on P10 of this thread, I posted some stuff about downloading/uploading certain blocks of memory in DFU mode, which can be done via commands or via this website...

https://devanlai.github.io/webdfu/dfu-util/

...using 0483 as the vendor ID.

I've no idea what all the various memory blocks in the Orba are, though I'm quite interested in getting a better understanding of how to read/write these areas on MCUs. It might be worth trying to map them out. I don't know if any of the ones accessible from that website might contain Orba memory values that change during use (memory data, key, quantization mode etc). I think those DFU ones might be associated with the STM32 rather than the ESP32, and are probably just static firmware data, but my knowledge of this stuff is very sketchy. It might possibly be worth trying a download/compare/settings-change/download cycle with these.

Great - glad you got the console working. It would be cool to add a Quantize on/off button to the Chord Fiddler if you can find a way to send these commands with a script or a web page. (I was wondering about creating some kind of terminal script file.) 

The "?" command does the same thing with my Orba. When I mentioned "ASCII animation", it's just a garbage string of characters that probably includes backspaces and things.

Since the Orba remembers quantise mode when you turn it off and on, maybe those elusive looper quantise snap settings stay in flash memory too. If we can find a way to upload/download blocks of Orba's memory, we could try changing things like quantise mode (also key/tempo etc) and comparing memory blocks to find these values; maybe even write to them.

A couple of the console commands seem to be read/write, or there might be a way to do that outside the "Orba terminal" program it's running, and talk to the Orba via the kind of commands seen in the flash-from-file log.  

Interesting about the hardware mode. If you flash it from file at some point, perhaps you could upload the full log for that, though I'm not going to encourage you to start flashing flashing from file etc unless you have to just in case something goes wrong. It's always bounced back for me so far though.

**********************************************

Re: XML, it was after noticing the "mode" tags in the songs files that I tried adding similar tags to the Looper info ones into the song and preset XML, but I haven't managed to detect any change from doing that yet. It might be like the intervals list, where nothing seemed to happen until I changed it in the code.

I'm still interested in the fact that the app code begins with a string that resembles one of these values, though I can't find it anywhere else. I wondered if the start of the app code might hold some of these values, or if it's just be a random fragment of unintelligible compiled code. Changing the app code isn't very useful anyway; definitely a last resort, and you have to match string length with any edits. 

I was wondering about the possibility of encoding values in the looper info header list and searching for that string. The other thing is that the only tag we know about, "quantizationMode", appears in the loop info list as "quantMode", so the other entries might also have different forms for the display entry and the XML field entry, if there even is one. The corresponding list with the "%u" values that I found in that .bin file look like formatting codes in C, from Googling.

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