Closed beemeeup closed 10 months ago
I don't own a Spark Mini, but from what I have found in the web it seems that opposed to its big brother, the Mini does not have preconfigured hardware presets. On startup, the Ignitron tries to initialize by setting to hardware setting 1. This seems to fail due to missing or different setup in the mini. Unfortunately, I cannot test it as I don't have one, so for now I am sorry to say that the Ignitron only supports the big amp.
Maybe someone else from the community can have a look at the code how it can be tweaked to work with the mini.
Ok. Thanks for looking into this.
Is there Something I can do to figure this out?
If you are good in programming, you could have a look into the code, if you can somehow change the way it initialized, e.g. not trying to set a hardware setting during initialization. You might also need to take care when changing settings to not switch to a hardware setting. Otherwise I would assume it should work.
@beemeeup if you are still interested in getting this to work, I have tried to change the code to initially switch to a custom preset, not a HW preset. As I don't own a Spark Mini, I have no possibility to test the code. Would you be able to check out the branch 20230630_enable_spark_mini_go, build and test? It should switch to the preset with number 1-1. You would still be able to then switch the Ignitron to a HW setting which would likely crash the Ignitron, but this is just to test if the missing HW presets were the root cause of your issue. If the initialization works for you, I could extend the code so you can select during build time which Spark model to use.
Please check and let me know if it works (or someone else who happens to read this)
Hi, just discovered your amazing project and testing with my MINI. Same issue here.
I'm trying the mini_go but it doesn't solve. I activated DEBUG define and added some serial print and I think the problem is processing a short message from MINI.
See attach debug file: debug_log1.txt
I think when it receive the F00101000501F7 message processBlock() function try to access to an array element that does not exists blk[18]... blk[20]...
What do you think about this? Can I patch it in some way?
@itarozzi Thanks for the log file. The message received from the amp seems to be an acknowledgment message. Strange is that the message is just the core part without the wrapper part (which starts with 01FE), but I am not 100% sure if the logging maybe happens after stripping the wrapper part. I have added some code to the branch to handle this acknowledgment, trying to ignore it when it is an incomplete message. Please try again after updating your code from the repository (same branch 20230630_enable_spark_mini_go) and checking the log.
@stangreg first of all thank you very much for your quick reply!
I tried the new version, but I think it doesn't solve.
I have 2 different behaviors with and without data files loaded in the spiffs file system.
I attach 2 new logs.
With data present, it crash again.
Without data it doesn't crash, but it start an infinite loop with messages you can see in the log.
If I can do more test please tell me.
PS: unrelated question, but usefull to better test the program. Using arduino IDE I can upload new sketch without delete data in spiffs. Using vscode/platformio it seems to recreate partition each time I upload new version, deleting data in spiffs. Do you know if there is a way to avoid it? debug_log2_without_data.txt debug_log2_with_data.txt
@itarozzi I have just checked the code again and noticed that I forgot to add a return statement in case of incorrect messages, so the behavior was actually the same as before. I have added the statement now and committed. Can you please update your code and try again? Sorry for missing this point.
Regarding the data, you definitely need to upload the data to make Ignitron work correctly, so let's continue with the data. As I am not using platformio, I cannot help you with that topic. I am using Sloeber for development.
No lucky with the last commit, same issue.
I also applied optimizations you wrote for the main branch (fbc6cb0077c1044b5f9d55d969edd4e78f40190f) but no differences.
I also already applied changes for stoi calls (4a5ad475dab58c7a6061187a0ba831b385e41b14) due to compile successfully; I think is a good idea to merge it to the MINI branch .
I then done other test:
Running the program without write SPIFSS data results on no crash, the display shows HW: 1 and pressing the switches 1-4 I can switch to hw preset 1 to 4 without issues. Changing bank results on inconsistent state, with display showing blank info and switches 1-4 not working, until I return in HW:1 mode. See log 3a
Commenting out the block where checked for spark_dc.activePreset()->isEmpty at boot time (ignitron.ino) no crash again, but it repeats init commands because isInitBoot remains true
Same as (2) but forcing isInitBoot to false, program crashes
Restored the commented block but commented out the spark_display.update() at the end of the .ino file; in this case the program doesn't crash. But I can see spark_dc.activePreset()->isEmpty is always true; in fact still looping in init boot with delay 2000 (inserted comment to be sure). But I cas see it the JSON preset in the log and the commands to set preset (See log 3b)
So we have 2 type of problems: active preset still empty even though it has been set and crash on update display when active preset is empty.
I tried to investigate about active preset assignement and I think the problem is the message F00101000501F7 received from the MINI that may be act as ack message but it is now ignored.
I tried to return MSG_PROCESS_RES_COMPLETE in case of that message but then the lastAck in the calling method is 0.
May be, in case of MINI ACK we need to assign other data before return, but my limited knowledge of the software makes it difficult for me to understand what.
You can see my currents mod in my forked repository (https://github.com/itarozzi/Ignitron/tree/20230630_enable_spark_mini_go), and the log 3c attached.
Thanks again for the support
@itarozzi I agree, I think the main issue is ignoring the acknowledgment as this is the trigger to know that the preset has been changed. I have now implemented a new behavior so that messages without a header are also processed. I did a number of changes and cannot test it on the Mini as I don't own one. I have thought tested the code successfully on my Spark 40.
Can you please update your code again based on my commits and try again?
WOW! Amazing!! Everything seems to work perfectly. Here in the laboratory I don't have the guitar to test, but looking at the display everything seems to be ok.
I tried again even without spiffs data and the HW preset switch still works!
Really good work! Compliments!
Now I'm going to try with the instrument connected to see if the sounds actually change.
Just one last question: is there a way, if the presets are present in spifss, to still enter HW switch mode? It could be useful when you test presets downloaded from the web using the spark app, before deciding to save them into ignitron. But this is an additional feature that is absolutely optional.
Thanks again a lot four your work and for sharing.
@itarozzi Wow, that is awesome, thanks for testing! If that works I assume that it now works for all Spark models. This was really bothering me.
If you read the history of this issue, I first suspected that the Mini and Go are musing HW presets and this was causing the issue. Now that I know that all models have HW presets, I think I can revert this small change and put it back to the default behavior.
I will let you know once I have cleaned up the code, would you then test this once more?
Regarding presets, I am not sure if I understand your request properly. Let me explain what a typical workflow could look like:
Please also check the description on GitHub, all modes and functions should be explained there. You can also use Ignitron to control certain apps via BT (only BLE), e.g. a looper app.
If I missed your point, please describe in detail which use case you are missing.
Regarding presets, you are right. My request has no sense.
I think the workflow you described is ok. I will try better and will read all the documents on GitHub.
Of course, when you will clean up the code I will be glad to do final test on my spark mini.
Final report after some test with the guitar... I claimed victory too soon :)
Ignitron seems to operate, the display reports change of presets and bank, but no sound changes on my spark mini.
Is like the preset is not received. In fact I can't see the led on the mini flashing (indicating the preset changes over the saved one).
But when I switch to FX mode I can enable/disable single effects and it seems to work well.
So finally: when I switch to HW preset 1-4 using the konb on the mini, the preset name is update on Ignitron display and in the FX mode I can toggle effects.
But changing preset from Ignitron switches, the display change but the sound is not affected.
Thinking about differences about presets for MINI and Spark40 I then tried to program some preset.
The AMP mode seems to work. I used with android, so switched to serial BT, and I can save presets to Ignitron. Ignitron is recognized as spark 40 and I can save new presets. But when I return in APP mode same results.
I don't know if presets for spark40 could be different from Mini or not. I will report the log again to see if there are some problem in commands or ack, switching presets
@itarozzi we are getting closer. Can you please send me logs from when you connect and then switch some presets, FX etc. all with Debug enabled?
Maybe that gives me a hint when I compare with logs for Spark 40.
debug_log4a.txt debug_log4b.txt debug_log4c.txt
Here the logs :
please, tell me if you need more
Here one last log because I discovered a different behavior in some cases:
In the log you can se Ignitron starting in APP mode. Then switch to preset with switch 1-4. After the commands there are no more print.
Then I changed the HW preset with the knob on Mini, and I receive the name of the new preset on display.
Now, when I switch preset I can see the JSON data of sent preset, but also the message processed referring to the HW preset. Don't know if it can help you or if is only a uncleared buffer somewhere.
But in any case the sound remain the same of HW preset, no Ignitron preset seems to be received.
PS: one last note: You can see I also tried to change the preset number form 127 to 0 in some presets in data directory, to mimic the same of the HW preset, but nothing changed
@itarozzi Thanks for the logs. In the first three logs I cannot find anything suspicious. I also tried once more with my Spark 40, and although I tested without plugging in a guitar, I could see that when setting a preset other than the HW ones, I can see the LED on the amp blinking, indicating that the preset is changed.
I have also switched back the implementation to include HW presets again (like in the main branch). Also there was an issue with the displayed data when switching HW presets on the device (I never used it actually). Now it should display the correct HW preset number when switching on the amp.
I did the latest changes on a new branch, 20240106_enable_spark_mini_go_hw_presets. Maybe you can check this out and let me know how it behaves with the Mini?
@stangreg Thanks for the new version. I tested the branch 20240106_enable_spark_mini_go_hw_presets and it works with HW presets. But same result with saved presets.
I then tried to verify the packet sent from Igitron to Mini, compared with packet sent from other working app. For that purpose I used the soundshed application (https://github.com/soundshed/soundshed-app) so I can use wireshark on my PC to capture bluetooth traffic.
I then choosed the same tone and sent from app to Mini, and then from app to Ignitron, saving them as preset in Ignitron memory. I captured the packets of all of them.
Finally I sent the same preset from Igritron to Mini and compared with packets from app.
I resumed that on the attached file. confronto-app-ignitron-nothingelse.txt
Here are some notes:
Now, my next step is to look in the code, where and how the packets are built (sparkMessage.cpp) to identify the bytes that are not the same, and why.
I hope this is the right way to reach the solution
@itarozzi Thanks for your thorough analysis! From what I can see, there is not much difference in the messages sent to the Mini. I think the small differences in the messages come from different ways to encode the float values of the parameters (could be rounding). The missing message which is sent from Soundshed but not from Ignitron is a request to the amp to send the current preset. This should not have an impact on changing the preset on the Mini, but I think at least it is a good way to check which setting is currently active on the amp. I have added the message to the flow, maybe you can check again?
When I did the initial implementation, I also struggled with actually activating the custom preset on the Spark. It was solved by actively setting the preset number to 127 (7F), the number is used by the Spark for custom settings other than HW presets. This is already present in the message flow.
BTW: If you are interested in the message format, there is a great document by paulhamsh: https://github.com/paulhamsh/Spark/blob/main/Spark%20Protocol%20Description%20v3.2.pdf
@stangreg Thanks, very usefull informations. I will test the new version on evening and double check the packets.
OT: I created a CheatSheet for Ignitron in https://github.com/itarozzi/Ignitron/tree/20240108_cheatsheet. If you think is a good idea, you can include it in your repo.
@itarozzi thanks for the cheat sheet, this is a very good graphical overview on the Ignitron modes! I have included in my repo and mentioned it in the Readme file. Just some minor observations in the file:
Looking forward to hear from your check!
ok @stangreg , I think I pretty much got it working :)
Your last commit has been usefull becasuse in the log I was able to see that the preset was not set (it was reloading the same previous HW preset).
I found the solution adding some delay between write messages. At line 229 in the SparkBLEControl.ccp file was already present a delay, but commented out. Adding a delay of 10ms is not enough. I had to set a delay of 50ms to make it working.
This introduce a bit of delay switching the 4 presets but at the moment is the best solution I found. I'll do some additional tests with less delay next days, but I think is not a big problem.
May be could be a problem using on-stage on live events, but is not my case. In that case I have in mind another solution, but I'll eventually write a new issue with enanchment idea
Now I need to stress-test Ignitron for stability and to see if the delay of 50ms is enough for every perset and condition. But we are almost at the end of the tunnel. Thanks again
@stangreg Regarding your comment about the cheat sheet I reviewed odg and pdf file. See my previous branch
@itarozzi Wow, that is great to hear! I had introduced the delay at some earlier development phase, but later it turned out it is not required. So maybe this needs to be reintroduced to support the Mini. Just one note, it might be that the delay needs to be introduced between commands and not between blocks. So you could also test to put the delay after the for-loop instead of within. Maybe it can also be reduced to increase responsiveness. Let me know the results and I can put the delay in (either in the for block or after).
The code has only some rudimentary message handling when it comes to subsequent commands. Main process is to only update the preset in the DataControl after receiving an Ack. Introducing more order handling based on message numbering will increase complexity substantially, I assume. So maybe the delay is the best solution based on requirements.
@stangreg I done last test. It works only with delay between blocks (minimum 50ms) and not with delay between commands (tried also with long delay of 200ms).
At the moment is enough for me. Now I'm going to unmount the breadboard and create the final case.
@itarozzi Alright, then I will add the 50ms (in the same place as the 10ms have been before), test and commit. As this seems to work universally now with both devices, I will also merge this into the main branch afterwards.
Thanks for your great help in getting this sorted! I am soon getting a Spark GO, so I can also test if it works with all three types.
@itarozzi I have now merged all changes into the main branch and checked in, please have a look if you want.
One more thing I noticed in the cheat sheet: When in AMP mode, long pressing the "Bank Up" button with toggle between the BT modes (BLE and Serial). This is missing in the cheat sheet.
One more thing I noticed in the cheat sheet: When in AMP mode, long pressing the "Bank Up" button with toggle between the BT modes (BLE and Serial). This is missing in the cheat sheet.
Fixed! Thank you
Today I also could test with a Spark GO and it worked out of the box like a charm. So now all three Spark devices work with Ignitron, great!
I will in consequence also close this issue as it seems to be resolved.
@itarozzi For your information, I have recently reworked the code for handling messages. This includes an automatic detection, which Spark model is connected so that the pedal can adapt to the right data sending format. I also think this removes the requirement of the delay between messages. To do the automatic detection, I request the amp name and evaluate. As you own a Spark Mini and I don't have a device to test, I could only guess what name the Spark Mini sends. Could you please build and deploy the current main branch and send me the output of the logs? It should log the device name during startup.
@stangreg Thanksfor your message.
Sure, here my log. Please write me if you need more. I received a new ESP32 board yesterday so I can restart to use and test Ignitron. At the moment I can see it connects to my MINI
rst:0x1 (POWERON_RESET),boot:0x17 (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:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Initializing
Operation mode (boot): 1
Last bank not full, filling with last preset to get bank complete
Last bank not full, filling with last preset to get bank complete
Stopping advertising keyboard
Starting scan
Operation mode: 1
======= Entering APP mode =======
Initialization done.
Found Spark, connecting.
Scan ended.
Connected to: f7:eb:ed:0d:95:6d
Subscribing to service notifications of FFC2
Notifications turned on
Done with this device.
BLE connection to Spark established.
Changing to HW preset 1...Message processed:
{"Amp Name": "Spark MINI"}
OK
Message processed:
{"PresetNumber": 0, "UUID": "1ccd55eb-d0eb-40f0-b274-8a8f3690182c",
"Name": " Clean for Ballads 2", "Version": "0.7", "Description": "", "Icon": "icon.png", "BPM": 120.0000,
"Pedals": [
{"Name": "bias.noisegate", "IsOn": false, "Parameters":[0.2182, 0.0649, 0.0000]},
{"Name": "LA2AComp", "IsOn": true, "Parameters":[0.0000, 0.7126, 0.7248]},
{"Name": "Booster", "IsOn": true, "Parameters":[0.4045]},
{"Name": "ADClean", "IsOn": true, "Parameters":[0.7428, 0.5986, 0.3978, 0.8976, 1.0000]},
{"Name": "MiniVibe", "IsOn": true, "Parameters":[0.3101, 0.6549]},
{"Name": "VintageDelay", "IsOn": true, "Parameters":[0.6640, 0.1889, 0.3450, 1.0000]},
{"Name": "bias.reverb", "IsOn": true, "Parameters":[0.2857, 0.4084, 0.2996, 0.7524, 0.3001, 0.2985, 0.2000, 1.0000]}],
"Filler": "33"
}
@itarozzi perfect thanks! I can now change the code accordingly to recognize the MINI properly. Once I have done this, may I contact you again to test and check it is properly working?
@itarozzi I am finished now with the code changes, you can test as soon as you are ready.
Sure, I will be able to do it in the afternoon. But what exactly should I test? Because even with the previous version it seemed to connect correctly to the mini
Il mer 28 feb 2024, 22:49 stangreg @.***> ha scritto:
@itarozzi https://github.com/itarozzi I am finished now with the code changes, you can test as soon as you are ready.
— Reply to this email directly, view it on GitHub https://github.com/stangreg/Ignitron/issues/12#issuecomment-1969978323, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANWUZP2UVJL2UT6KXKEH53YV6Q7TAVCNFSM5XESAJOKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJWHE4TOOBTGIZQ . You are receiving this because you were mentioned.Message ID: @.***>
@itarozzi Great, thanks! You can just test general behavior. The difference should be when you switch to custom presets. Also in general it should work much more stable. Previous versions sometimes failed to switch to a preset or was in general more unstable, which should have improved now. Also the speed/latency should be better, I reduced the delay between messages to 10ms and it works stable with the Spark GO. On the other hand I had to reduce the delay because with the GO and MINI, the message size is smaller so the number of messages increased.
@stangreg I'm testing the new version with my MINI, and in general seems to work very well. It is well responsive and I can switch throught the bank and presets with minor latency.
But I noticed a problem: sometime it return to HW1 and from that point it seems out-of-sync and sometime reboots.
I'm debugging. Is not related to a particular bank or present, I can't yet found a particular way to reproduce the problem, but it happen.
Now I will enable debug flag and will do additional test. Meanwhile here the log without DEBUG.
Do you prefere continue here or do you prefere I open a new issue?
Changing to preset 01-3...OK
OK
Changing to preset 02-1...OK
OK
Changing to preset 02-2...OK
OK
Changing to preset 02-3...OK
OK
Changing to preset 02-4...OK
OK
Changing to preset 02-3...OK
OK
Switching Off effect Booster...OK
Switching On effect Booster...OK
Changing to preset 02-2...OK
OK
Changing to preset 02-4...OK
OK
Changing to preset 02-1...OK
OK
Changing to preset 02-2...OK
OK
Changing to preset 02-3...OK
OK
Changing to preset 03-1...OK
Message processed:
{"NewStoredPreset": 128}
Message processed:
{"New HW Preset": 128}
Requested preset out of bounds.
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x401b3733 PS : 0x00060a30 A0 : 0x800d8935 A1 : 0x3ffcde00
A2 : 0x3ffcdfa4 A3 : 0x00000000 A4 : 0x3f41fb64 A5 : 0x3ffd6cdc
A6 : 0x00000010 A7 : 0x00000001 A8 : 0x3ffcdfac A9 : 0x3ffcddd0
A10 : 0x3ffcdf7c A11 : 0x3f41fb63 A12 : 0x3f41fb64 A13 : 0x0000ff00
A14 : 0x00ff0000 A15 : 0xff000000 SAR : 0x00000010 EXCCAUSE: 0x0000001c
EXCVADDR: 0x00000000 LBEG : 0x4009273d LEND : 0x4009274d LCOUNT : 0xffffffff
Backtrace: 0x401b3730:0x3ffcde00 0x400d8932:0x3ffcde20 0x400d8c1b:0x3ffcdff0 0x400d2a02:0x3ffce030 0x40101eb9:0x3ffce050
ELF file SHA256: 3391fc92c5c2e59b
Rebooting...
ets Jul 29 2019 12:21:46
rst:0xc (SW_CPU_RESET),boot:0x17 (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:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Initializing
Operation mode (boot): 1
Last bank not full, filling with last preset to get bank complete
Last bank not full, filling with last preset to get bank complete
Stopping advertising keyboard
Starting scan
Operation mode: 1
======= Entering APP mode =======
Initialization done.
Found Spark, connecting.
Scan ended.
Connected to: f7:eb:ed:0d:95:6d
Subscribing to service notifications of FFC2
Notifications turned on
Done with this device.
BLE connection to Spark established.
Changing to HW preset 1...Message processed:
{"Amp Name": "Spark MINI"}
OK
Message processed:
{"PresetNumber": 0, "UUID": "1ccd55eb-d0eb-40f0-b274-8a8f3690182c",
"Name": " Clean for Ballads 2", "Version": "0.7", "Description": "", "Icon": "icon.png", "BPM": 120.0000,
"Pedals": [
{"Name": "bias.noisegate", "IsOn": false, "Parameters":[0.2182, 0.0649, 0.0000]},
{"Name": "LA2AComp", "IsOn": true, "Parameters":[0.0000, 0.7126, 0.7248]},
{"Name": "Booster", "IsOn": true, "Parameters":[0.4045]},
{"Name": "ADClean", "IsOn": true, "Parameters":[0.7428, 0.5986, 0.3978, 0.8976, 1.0000]},
{"Name": "MiniVibe", "IsOn": true, "Parameters":[0.3101, 0.6549]},
{"Name": "VintageDelay", "IsOn": true, "Parameters":[0.6640, 0.1889, 0.3450, 1.0000]},
@itarozzi Thanks a lot for this first test. I think the crucial part is this:
Message processed:
{"NewStoredPreset": 128}
Message processed:
{"New HW Preset": 128}
Requested preset out of bounds.
I think DEBUG output will definitely help here. I have also noticed a similar behavior with the Spark GO and any log can help to identify the issue. I think it is better to open a new issue as this one is officially closed and the issue is actually different to the original one.
Thanks again for your support!
@itarozzi Before you open a new issue, I could reproduce and (hopefully) fix the issue. Sometimes the Spark sends back a preset change message instead of an Acknowledgment (I think this is a bug on Spark end). I am handling this behavior now and it should fix the inconsistency. Please try again from main branch. If you still face problems, please open a new issue.
@stangreg Sorry I openend the issue without read this new message.
At the moment I'm not at home but tomorrow I will test your last commit and in case it works we can close/delete my new issue
@stangreg I updated to new version and stressed the system and now it seems to work well!
Great work as usual. Thanks a lot!
Describe the bug I Power on the Ignitron while my mini is in BLE Connect waiting saite (slow blinking blue LED). But the Ignitron does not seem to connect.
The Amp is shown on the Phone as "Spark 40 BLE"
Some times the Ignitorn shows : HW $ 1
$ is the Bluetooth symbol.
This is shown for about 10 sec and then Ignitron seems to restart
Here is the Serial Monitoring which shows an error.
Last bank not full, filling with last preset to get bank complete Starting scan Initialization done. Found Spark, connecting. Scan ended. Connected to: f7:eb:ed:0a:ad:26 Subscribing to service notifications of FFC2 Notifications turned on Done with this device. BLE connection to Spark established. Changing to HW preset 1 Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x400d273f PS : 0x00060730 A0 : 0x800e3cc8 A1 : 0x3ffd28e0
A2 : 0x3ffd2914 A3 : 0xfffffff4 A4 : 0x3ffd4d6c A5 : 0x3ffd4e00
A6 : 0x00000059 A7 : 0x00000059 A8 : 0x800d2738 A9 : 0x3ffd28e0
A10 : 0x3ffd4d6c A11 : 0x3ffd4ef8 A12 : 0x00000014 A13 : 0x00000001
A14 : 0x00060021 A15 : 0x00000000 SAR : 0x00000008 EXCCAUSE: 0x0000001c
EXCVADDR: 0xfffffff8 LBEG : 0x4000c349 LEND : 0x4000c36b LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000
Backtrace: 0x400d273f:0x3ffd28e0 0x400e3cc5:0x3ffd2900 0x400d4cbf:0x3ffd2940 0x400d4e49:0x3ffd2a80 0x401b3cee:0x3ffd2ac0 0x400e5761:0x3ffd2ae0 0x400ec959:0x3ffd2b60 0x400ec9a3:0x3ffd2b80 0x400ede58:0x3ffd2ba0 0x400ec669:0x3ffd2c00 0x400eaac5:0x3ffd2c20 0x400f1fdd:0x3ffd2c50 0x400f09fd:0x3ffd2c80 0x400f0a0f:0x3ffd2ca0 0x400f7d42:0x3ffd2cc0 0x400e624f:0x3ffd2ce0 0x40091082:0x3ffd2d00
Rebooting... ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (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:1 load:0x3fff0018,len:4 load:0x3fff001c,len:1044 load:0x40078000,len:10124 load:0x40080400,len:5856 entry 0x400806a8 Initializing Initial button setup Operation mode: 1 ======= Entering APP mode ======= Last bank not full, filling with last preset to get bank complete Last bank not full, filling with last preset to get bank complete Starting scan Initialization done. Found Spark, connecting. Scan ended. Connected to: f7:eb:ed:0a:ad:26 Subscribing to service notifications of FFC2 Notifications turned on Done with this device. BLE connection to Spark established. Changing to HW preset 1 Guru Meditation Error: Core 0 panic'ed (LoadProhibited). Exception was unhandled. Core 0 register dump: PC : 0x400d273f PS : 0x00060730 A0 : 0x800e3cc8 A1 : 0x3ffd28e0
A2 : 0x3ffd2914 A3 : 0xfffffff4 A4 : 0x3ffd4d6c A5 : 0x3ffd4e00
A6 : 0x00000059 A7 : 0x00000059 A8 : 0x800d2738 A9 : 0x3ffd28e0
A10 : 0x3ffd4d6c A11 : 0x3ffd4ef8 A12 : 0x00000014 A13 : 0x3ffd4af0
A14 : 0x00000000 A15 : 0x00000003 SAR : 0x00000008 EXCCAUSE: 0x0000001c
EXCVADDR: 0xfffffff8 LBEG : 0x4000c349 LEND : 0x4000c36b LCOUNT : 0x00000000
ELF file SHA256: 0000000000000000
Backtrace: 0x400d273f:0x3ffd28e0 0x400e3cc5:0x3ffd2900 0x400d4cbf:0x3ffd2940 0x400d4e49:0x3ffd2a80 0x401b3cee:0x3ffd2ac0 0x400e5761:0x3ffd2ae0 0x400ec959:0x3ffd2b60 0x400ec9a3:0x3ffd2b80 0x400ede58:0x3ffd2ba0 0x400ec669:0x3ffd2c00 0x400eaac5:0x3ffd2c20 0x400f1fdd:0x3ffd2c50 0x400f09fd:0x3ffd2c80 0x400f0a0f:0x3ffd2ca0 0x400f7d42:0x3ffd2cc0 0x400e624f:0x3ffd2ce0 0x40091082:0x3ffd2d00
Rebooting... ets Jun 8 2016 00:22:57