Problems with Internal EEProm

Testing/Troubleshooting
1

I have reached the final hurdle with my organ project.

The organ itself is working.  The last stage is the memorised setup.  I use the internal EEprom to store the pin Numbers (DIN) which are associated with the stops, couplers and pot values.  There are 6 Memory buttons and ultimately there will be 21 stored values associated with each of the 6 Memory buttons.

I am now able, using the MIOS_EEPROM_Read function to obtain the relevant stored DIN values to generate DIN_Notify_Toggle functions.  These effectively will simulate the the pressing of the organ stops.

Using the memory buttons in “Playback” mode I sometimes achieve the correct results. I am using Midiox to record the Sysex messages,

There is a gremlin that sometimed adds an additional Sysex message to the end of a correct larger Sysex message.

This is F0 00 00 7E 40 00 01 F7

There is a definite pause between the correct Sysex message and the additional bytes.  I would estimate about 1/3 to 1/2 second.

I should add, that the sysex messages generated directly by the pushbutton stops are consistently correct.

Those generated indirectly are sometimes faulty.

The additional Sysex message when it occurs is the same.  It does not seem to relate to the beginning or (end) of the adjacent sysex message stored in the bankstick.

It seems to be somewhat related to certain Memory buttons but not consistently.

Does anyone recognise the message?

Could it be a message from the core?

Your help will be appreciated.

Robin

Since sending the post I remembered that the sysex message is the core upload request.  Why would this be generated?

2

Since sending the post I remembered that the sysex message is the core upload request.  Why would this be generated?

Cause the core just restarted itself after a timeout?

Is it possible that the memory reads are causing a delay? You could try hardcoding the data into the functions to test it, that way no eeprom read happens, which is probably what is causing the delay… How many bytes are you reading before the sysex is sent? You might want to use a page read instead, it’s a much faster way of grabbing a lot of bytes.

3

Hi Robin,

the upload request (or reset) is caused by the watchdog timer. If a function takes more than 1 second, you have to insert

__asm
  clrwdt
__endasm;
[/code]









within the "big loop" (which sends a dump, or writes something into EEPROM) in order to ensure, that the watchdog timer won't overrun and accordingly trigger the reset







Best Regards, Thorsten.
4

Hello Thorsten

Thanks for confirming that this is  a watchdog timer problem.  I have the clrwdt in my bankstick read dump but the EEProm read is only one byte.

Would I need to take any such care with the following repeated functions?

        DIN_NotifyToggle ((MIOS_EEPROM_Read (q + 1)), 0x00);

DIN_NotifyToggle ((MIOS_EEPROM_Read (q + 2)), 0x00);

DIN_NotifyToggle ((MIOS_EEPROM_Read (q + 3)), 0x00);

5

Hi Robin,

yes, you have to take care, that no recursion happens. If this is the case, the clrwdt won’t help, instead the application will freeze, so that you have to trigger a reset manually (power-off/on).

In fact, one of the purposes of the watchdog timer is to terminate such programming errors gracefully with a reset, so that somebody is able to upload the corrected code w/o reseting the core manually.

Back to the topic: recursion means, that the DIN_NotifyToggle calls itself several times. If there is no condition which terminates this process, then the stack will overflow sooner or later, the whole application will crash.

So, all what you have to do is to ensure, that the button numbers which are forwarded to the DIN_NotifyToggle function will not execute the part of the code, which will call DIN_NotifyToggle again

Best Regards, Thorsten.

6

I  examined my code to check for recursion.  I could not find out why this was occurring.  I spent a couple of hours trying various things but nothing worked.  I kept getting core resets.

In the end I decided to use an alternative method that did not involve DIN_NotifyToggle.  The method was more straightforward and seems to work wih no suggestion of core resets.

The memorised setup seems to work and I am tidying up the code and looking at the operation to ensure that the button operation is ergonomic and  reasonably intuitive.

Regards Robin

7

Problem still remain despite my earlier optimism.

I have a frustrating problem with Sysex messages generated indirectly via the Memorised Setup.

When Sysex messages are generated direcly via the organ stop pushbutton (DIN) they are rock solid. However

when they are generated by storing the same DIN on EEProm (internal not Bankstick) they fail about 1 in 9

times. In this case Midi-ox freezes.

I had a similar problem with a different method using DIN_NotifyToggle.  In that case core resets occurred.  This is not the case here. The following CC’s appear on Midi-ox after releasing from the freeze.  I need to reset the Midi out on Midi-ox.

00000006  1  –    B4    40    00    5  —  CC: Pedal (Sustain)

00000007  1  –    B5    40    00    6  —  CC: Pedal (Sustain)

00000008  1  –    B6    40    00    7  —  CC: Pedal (Sustain)

00000009  1  –    B7    40    00    8  —  CC: Pedal (Sustain)

0000000A  1  –    B8    40    00    9  —  CC: Pedal (Sustain)

0000000B  1  –    B9    40    00  10  —  CC: Pedal (Sustain)

0000000C  1  –    BA    40    00  11  —  CC: Pedal (Sustain)

0000000D  1  –    BB    40    00  12  —  CC: Pedal (Sustain)

0000000E  1  –    BC    40    00  13  —  CC: Pedal (Sustain)

0000000F  1  –    BD    40    00  14  —  CC: Pedal (Sustain)

00000010  1  –    BE    40    00  15  —  CC: Pedal (Sustain)

00000011  1  –    BF    40    00  16  —  CC: Pedal (Sustain)

There are 36 bytes in the present case whereas there were 8 bytes before.  See the earlier posts in this thread.

There is no definite consistency with the results and noise or interference must be a possibility.

The direct method is a  result of pressing a pushbutton say 0x08,  the memorised set up stores 0x08 in EEProm and later on in Playback mode the 0x08 is read and then uses the same logic to generate the Sysex message.

I suppose that Midi-ox may be more noise sensitive than the Synth.  However that may be wishful thinking.

Any thoughts anyone?

Robin

8

Hi Robin,

when invalid or incomplete MIDI events are sent, MIDI-Ox displays more bytes than really received.

It could be, that the code sends only the MIDI status (0xb4, 0xb5, 0xb6, …), but not the remaining two bytes (CC number and value)

Best Regards, Thorsten.

9

After receiving Thorstens reply I looked again at the code that appears after Midi_ox is reset.

I thought that I should also check my application that deals with the organ keys.  This is a fairly simple program but does have Midi Out.  I also looked at my Button and Led test program for the console.  This has no Midi.

I have found that after resetting Midi-ox the following sequence is is alway present for the applications that have Midi.

 

00000006  1  –    B4    40    00    5  —  CC: Pedal (Sustain)

00000007  1  –    B5    40    00    6  —  CC: Pedal (Sustain)

00000008  1  –    B6    40    00    7  —  CC: Pedal (Sustain)

00000009  1  –    B7    40    00    8  —  CC: Pedal (Sustain)  etc etc up to 12 lines

Therefore the problem might be with Midi-ox.

I looked at the Midi-ox website and found some discussions about large sysex dumps.  This is exactly what I am doing.  The settings I was using to configure Midi-ox were too small.  I increased the number to 512 and size of the buffers to 512 for both input and output and the system worked properly with no Midi-ox resets.

There is a lot to learn.

Robin

10

Hi Robin,

wow, this special behaviour of MIDI-Ox on SysEx buffer overruns was new to me! Good to know!

Best Regards, Thorsten.