@BJG145 said:
I too have had this thought and I remember this node:
<Mode name="Bass" quantizationMode="1" volume="200">
I suspect this information is being written to the same area and somehow bytes are very limited.. Or maybe they had a build ready for release that passed all volume-per-part tests and they didn't want to risk adding in quantization.
@BJG145 said:
>" It rebooted itself and when it returned a song that I was working earlier was now in memory"
The same thing happened to me once. The Orba was playing a song, then it crashed, and started playing an earlier song, which I'd always found puzzling. I hadn't made the connection. I even thought I might have imagined it, but the thing was gaslighting me.
To recap, it's possible to talk to the Orba in several different modes.
1) DFU Mode. In this mode we can talk to the STM32 via the App’s firmware update, via dfu-util.exe, or the DFU website. It presents four different storage areas shown by dfu-util.exe -l.
serial="STM32FxSTM32"
[0483:df11] alt=3, name="@Device Feature/0xFFFF0000/01*004 e",
[0483:df11] alt=2, name="@OTP Memory /0x1FF07800/01*528e", serial="STM32FxSTM32"
[0483:df11] alt=1, name="@Option Bytes /0x1FFF0000/01*048 e", serial="STM32FxSTM32"
[0483:df11] alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg",
The flash-from-file log has entries such as:
dfu-util.exe -d 0483:df11 -a 0 -s 0x20010000
Here 0483:df1 identifies the device, -a identifies one of the above four storage areas by their “alt” number, and -s identifies the address for the file transfer.
The tiny low-level “Option Bytes” area is refreshed in some way, and “Internal Flash” receives 0x2 (no text, changes) together with 0x8 (console text, no changes). These files are apparently created by the App, which drops them in a temp folder and clears them away afterwards. As for the other two storage areas, “OTP” is non-writeable and “Device Feature” doesn’t seem included.
2) Normal mode. In this mode we can talk to the ESP32 via the App or the console. I’ve found that if you come out of the App, you can’t connect to the console until you’ve powered the Orba off and on again, as if the Orba hasn’t disconnected ready for the next call.
3) Programming mode. The second half of the firmware-from-flash process turns this on and then off again automatically. The only way I’ve found to get it into this state and keep it there is via console “B”. Unfortunately this doesn’t always seem to work reliably (it should end with “waiting for download”), so I’ve sometimes had to go through flash-from-file, then turn the Orba off and on again to be able to connect via the console, then use “B” to get it into programming mode. Once there you can carry out Flash read/write via esptool.py.
During flash-from-file, the ESP32’s Flash receives a system file called bootloader, then delorean.bin, then another system file called partitions_singleapp. These three are included in the downloadable firmware zip. One thing that puzzles me is that the flash-write entries for the first two both start with:
Writing at 0x00010000
Why carry out two consecutive writes to the same place…? Maybe it’s ESP32 standard operating procedure. (The small final file goes to 0x00008000.)
The Orba looks unresponsive in both DFU and Programming modes. There’s also another couple of states it can get stuck in. If you pull out the USB cable about halfway through flash-from-file you can get into an unresponsive spinning-white-circle pattern which might relate to flashing the sensor. Sometimes I’ve found it can also get into a state with a flashing Oct light; and I’m not sure what that means, but although it still plays, I’ve sometime had to use flash-from-file to be able to connect to it again when it gets like that.
I hadn’t appreciated that these MCUs seem to work basically like a miniature computer; loading programs and data from storage into RAM, working with them, and saving them again. (?)
My current theory is that flash-from-file preps the STM32 with 0x8 which runs the console and possibly the main performance activity, and 0x2 which is still a mystery. It then preps the ESP32’s 4MB Flash with delorean whch handles Bluetooth, maybe performance data, maybe system settings, possibly sample data if the function was available.
On startup, this stuff is loaded from the 4MB Flash storage into the 4MB Winbond aka Tony’s chip.
On shutdown, and possibly also other times, it gets written back. I say “possibly other times” because of the changelog comment: “Fixed issue where stuck notes were possible if pads were played during flash writes”.
I had a quick look to see if there might be a way to examine RAM contents. It seems external RAM can be configured for the ESP32 in various ways described here:
I'd guess that it uses the default, “Provide External RAM via malloc”, given that “malloc” crops up quite often in the .bins. I can’t see a simple user-friendly utility like dfu-util or esptools.py to interrogate it though, and since it gets written to Flash at shutdown anyway I’m happy to stick with those. It’s just worth bearing in mind that if you make changes between Flash grabs without powering off, you might not capture the change. I seem to remember that console “W” forces RAM write to Flash (before kicking you out of Putty) so I’ll experiment with that.
In light of RAM/Flash writes I’ll have another go at trying to capture changes in the ESP’s 4MB Flash after changing performance data and settings…
Carrying out these 4MB Flash comparisons is difficult because "B" for "Programming mode" is very flaky. It often stalls and I have to tinker around with the Orba for a while, flashing it, sending new songs to it, restarting it, until I can get it back into programming mode again...and by that time you've lost the changes you were trying to compare.
However, I've managed to get a new grab to check against the one I posted before, and the only difference seems to be in a memory area immediately after delorean.bin containing a lot of this...
LE_LOCAL_KEY_IRK = 10d037d698afadd868f0098d1d9afa42
LE_LOCAL_KEY_IR = 47b6e7029880abba8de07bf71e3fa944
LE_LOCAL_KEY_DHK = a85872664501ebb925cf1ca3af6854e4
LE_LOCAL_KEY_IRK = 10d037d698afadd868f0098d1d9afa42
LE_LOCAL_KEY_IRK = 10d037d698afadd868f0098d1d9afa42
LE_LOCAL_KEY_IR = 47b6e7029880abba8de07bf71e3fa944
LE_LOCAL_KEY_DHK = a85872664501ebb925cf1ca3af6854e4
LE_LOCAL_KEY_ER = 98db770f480e43c82c56bd27c24ab40d
From a quick Google, this looks like Bluetooth data. (?) It tends to confirm what the "parttion list" indicated, that this storage area is used primarily for delorean and Bluetooth. I'm now thinking that the write-from-memory that occurs on shutdown may send data to a couple of different areas; this Bluetooth stuff to the ESP's Flash (though why you'd want to keep it I've no idea), and other things to the STM32 Flash (eg 0x2). I think I'll take another look at that, because it's much easier to access.
Still not sure whether those above strings might contain note data. It would seem a strange and unlikely format for it. On the other hand, I thought the STM Flash size was more limited...will need to check...
...yeah, the STM32F730 only seems to have 64KB Flash.
https://www.st.com/en/microcontrollers-microprocessors/stm32f7x0-value-line.html
Mind you, it does run out of notes pretty quick.
>"This Bluetooth stuff to the ESP's Flash (though why you'd want to keep it I've no idea)"
...pairing info, I suppose...?
(...either way, I'm definitely tending towards the indecipherable 0x2 area as the repository of performance data and settings...)
[0483:df11] alt=0, name="@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg",
I now seem to remember doing this sum before in this thread.
4x16KB + 1x64KB + 3x128KB = 512KB seems to be the total Flash available to the STM32. Maybe I need to break away from dfu-util transfers copied from the log and try grabbing some different chunks; after all, note data is obliterated by flash-from-file.
Great Work!
On another note I'm looking at various ways to manipulate song data. I've found this great online sequencer that can interface with Orba and then export midi files. I think I could write a script that converts these midi files to song files :) The one problem is that it appears that Orba will only output sound from the voice mode that it is currently in. For example, if I plug in a midi keyboard and send notes to Orba, it plays those notes through the current voice mode (e.g. Drums) regardless of the channel I'm sending those notes on. I swear at one point that I could change the channel on my external keyboard and target the four voices by using midi channels [1,9,10,16]?!
Trying different addresses for dfu-util was a bit of a rabbit hole.
The specific version of the STM32F730 is the R8T6.
@Internal Flash /0x08000000/04*016Kg,01*64Kg,03*128Kg
We've seen that 0x20010000.bin is sent to 0x20010000....
Downloading to address = 0x20010000, size = 125792
...and 0x8000000.bin is sent to 0x08000000.
Downloading to address = 0x08000000, size = 65536
...and at first I'd thought there might be more, but dfu-util wouldn't accept any other address values. In order to find out what these values are, you have to look at the datasheet. I ended up downloading a database called Keil Tools which produced the following info.
CPU=IRAM(0x20010000,0x30000) IRAM2(0x20000000,0x10000) IROM(0x08000000,0x10000) IROM2(0x00200000,0x10000)
CPUTYPE("Cortex-M7") FPU3(SFPU) CLOCK(12000000) ELITTLE
FLDLL=UL2CM3(-S0 -C0 -P0 -FD20010000 -FC1000 -FN1 -FF0STM32F7x_64_AXI -FS08000000 -FL010000 -FP0($$Device:STM32F730R8Tx$CMSIS\Flash\STM32F7x_64_AXI.FLM))
MON=SARMCM3.DLL (" -MPU") TCM.DLL ("-pCM7")
SIM=SARMCM3.DLL (" -REMAP -MPU") DCM.DLL ("-pCM7")
SVD=$$Device:STM32F730R8Tx$CMSIS\SVD\STM32F730.svd
The two values from the log correspond to "IRAM" and "IROM". "IRAM2" and "IROM2" don't work either; nothing else works.
I think flash-from-file must be sending 0x20010000.bin to the STM32's standard RAM, not Flash after all. (?) Maybe that explains why it changes so widely and randomly between grabs.
>"I swear at one point that I could change the channel on my external keyboard and target the four voices by using midi channels"
I can't get that to work either...
>"@BJG145 Looking for your thoughts on this"
I was just taking another look at this to to try and follow the bit where he's explaining that there might be a bit over 4MB on a 4MB Flash chip so you might want to check you're not missing anything; it's at this point.
https://youtu.be/2GwzbBn7uRw?t=676
And I realised...d'oh, that Winbond chip isn't RAM at all...that's the 4MB Flash.
He goes to a datasheet for his chip where he identifies a value of 3FFFFF = 4194303.
The corresponding value on the datasheet for the Winbond 25X40CL shown above is 07FFFF = 524287
So, I just tried:
D:\orba\esptool.py read_flash 0 0x07FFFF complete_flash.bin
esptool.py v4.1
Chip is ESP32-S0WD (revision 1)
Read 524287 bytes at 0x00000000 in 47.4 seconds (88.5 kbit/s)
File attached FWIW. Wait, that's on 512KB.
So confusing. Will have to revisit.
It seems like the Orba will receive multiple midi channels according to this:
https://artiphon.freshdesk.com/support/discussions/topics/44001019898
But somehow this isn't working for me. I'm starting to think that having the quantize mode on is causing some issues but I can't put my finger on it.
I should have read Tony's original comment about this Winbond chip more carefully.
>"Winbond 25x40CL (not far from the AKM DAC) is a 4Mb (ie 512KB) serial flash memory."
I've been looking at "4Mb" and thinking, "four megabytes". But 4Mb is four megabits, which is only 512KB.
The ESP32-SOLO-1 has its own 4MB internal Flash as well (along with various blocks of RAM).
Auto-detected Flash size: 4MB
If the ESP32 has 4MB Flash, why add another 512KB Flash chip...?
Winbond is physically closer to the STM than the ESP. I don't know if that's relevant. I'm currently not sure which of those two chips can access it...(maybe even both?)
I don't know why the ESP32 would be interested in an extra 512KB if it's already got 4MB, unless it's a performance thing; the Flash-starved STM32 with its 64KB would seem more in need of it. On the other hand, that might explain those two flash-from file writes at the same address (bootloader and delorean).
20 Jun 2022 9:29:59pm - Compressed 24848 bytes to 14805...
20 Jun 2022 9:29:59pm - Writing at 0x00001000
20 Jun 2022 9:30:36pm - Compressed 702032 bytes to 407879...
20 Jun 2022 9:30:36pm - Writing at 0x00010000
The log output doesn't show all the exact commands taking place behiond the scenes. With the dfu-util writes, we see all the parameters for the command, but with the esptool.py writes, we don't. As well as an option for memory address, there might be an unseen option to identify the Flash storage device; either the ESP32's internal 4MB Flash or the Winbond's external 512K.
That leaves a couple more routes to explore:
1) Finding out how to read the Winbond Flash
2) Finding the real upper limit of the ESP32's 4MB Flash, as with the Winbond
Andrea Mannocci
This thread is intended to gather the feedback of Orba tinkerers.
28 people like this idea