2----if i put only one core with mios 1.8 and 1.7a the system if fully operational(i tested it with a bankstick that i removed now)
when you test one core and say it works, are you test only your first core or each core individually?
if all your cores work individually it may be that you have not assigned unique id headers for each of your pics. you can change the id headers with the change_id program from troubleshooting in the mios download section. don’t forget to look up the midibox sid docs to determine which header ids you should use.
Ok, so the common trouble with customized PCB layouts… :-/
Let’s work through it: a big change between MBSID V1.7a (which works with any MIOS version) and MBSID V1.7b and higher is the external clock synchronisation, which avoids timing violations between Core->SID register transfers. This change requires, that either the clock output at PIC pin RC2 is directly connected to the SID clock input (no 1MHz oscillator, best solution), or that it is at least free (not clamped to ground - like on the original PCBs).
If RC2 is clamped to ground or +5V, the application will hang up and reboot. Is this the case with your own PCB?
Another point: is the 1k pullup at RA4 connected to the PIC? If not, the application could read random signal states, sometimes assume that a BankStick is connected, try to write into the not existing bankstick (formatting procedure), wait endless for a response and finally reboot (watchdog timeout)
So: is the 1k Pull Up R2 connected to the core?
what happens when you are uploading the MIDIO128 application. Are you able to trigger a >>single<< note event with each button, and two note events with each encoder?
do you notice reboots when MIDIO128 is running? Under which circumstances is it rebooted?
So, do I read this correctly: it’s a different button now, and with MIDIO128 the buttons don’t reset the core?
Are you uploading code without feedback? This is very unsecure - are you doing this, because the feedbacked method doesn’t work? Do you see error messages during the upload of code?
If you are using the “feedback from core” option, the delay value won’t be taken into account. In this case we only know, that there is some kind of random unstability.
Which revision ID is displayed, when you are uploading the “revision_id_v1_0” application?
does the PIC reboot when MIDIO128 is running and you press the buttons (one after another)?
I’m asking you all the questions to find a simple solution how we can continue with debugging. If the reset cannot be reproduced with an application like MIDIO128, you will have to modify the code of MIDIbox SID (based on the instructions I will give you) in order to find out the root cause.
If you can reproduce the reboot with MIDIO128, everything will be easier for you (not for me…)
What you can also do in the meantime:
upload MIOS V1.9c from MIOS Studio with feedback (to ensure that the MIOS is really complete)
install MPLAB, so that you are able to build .hex files
Hm, this lets the question open, why did it work under MIOS V1.8 with the old PSU? Or was this just an assumption (it seems, that effects where more or less random - first it was the edit button, later the filter button which caused the reboot)
Slave/Humm: enabling the Link button is important, otherwise the slave won’t receive MIDI data.
You can debug the slave exactly like you would debug the master core. You can run the MBSID interconnection test, you can interchange modules, you can access the slave directly from a MIDI keyboard or the PC in order to get it running…
the sid works under MIOS V1.8 with the old PSU maybe because the pic was burnt by a friend of mine last year for the prototype we made and i didn’t try to re-burn it as i wanted to keep it as a secure pic .
the psu was probably un-stable and the midi dump too.
so the system was stable even with a bad psu BUT BUT BUT because the pic was done with another machine …i’m sorry about the confusion.
i have no sound from slave even with link button (witch flashes)
