MIOS problem

[Thomas]

Hi!

Seems I have to step in every trap that can happen...murphy rules...

Ok...I noticed that my board is wrong. The mux-lines for AIN-multiplexer are interchangend.

A, B, C ist normally connected to pins RC0, RC1, RC3

On my board RC2, RC1, RC0. Don't know how this could happend. Maybe are writing error. :(

No problem I thought and changed the ain EQU in the mios-sources, not more.

(mios 1.9)

BUT: the resulting hex-file differs from the original one (mios_update1.9/pic18f452/midi/mios_v1_9_pic18f452.hex) in five lines. (not only in two bytes as I expected). 

And after I loaded my software, mios stops working and sends the initial request sysex-string every 2s.

I changed nothing in the C-wrapper file. Except that I added my own software files. Nor wrote I explicitely into RAM or flash. I only use global and local C-Variables and arrays. No dynamic memory allocation or write-operations via pointer.

During compiling of MIOS (with MPLAP v7.31) I get the warning

"operand of HIGH high operator was larger than H'FFFF'".

(line 67 of macros.h)

Any ideas what happed?

Any ideas where to start debugging?

[Thomas]

Forget what I wrote: even with the "normal" MIOS version, MIOS seems to be corrupted after uploading block 3B00-3BFF of my own software via sysex. (no "received checksum" any more)

[TK.]

Hi Thomas,

debugging: just open the "main.lst" file and search for the error message there, it helps to understand, which line of code has caused this warning.

With the normal MIOS version, you should always receive a checksum... did you ever notice problems with your MIDI interface before?

Best Regards, Thorsten.

[Thomas]

Hi Thorsten!

With the normal MIOS version, you should always receive a checksum

But I did! Always when I load my new software I got no checksum after block in the 3000-range.

Not always 3B00-3BFF, sometimes 3F00 or 5xxx.

MIOS upload and upload of examples work. That's why I doubt it's a MIDI-problem.

I have newer a problem with uploading MIOS, except that once it was so corrupted that I had to

re-burn the bootloader.

I forgot to mention that I go the error string <sysex header> <device id> 0E 0B 00 7F. But you only decripted error messages up to 0A...

After uploading my software MIOS is corrupted an sends only initial requeststrings.

Display shows not "READY." but something like

#######öp#######

################

I have some ideas at the moment:

1. wrong version of C-wrapper?

(Can this be? They only differ in the upper code range in linker script I think)  2. bug in c-warpper(?) or  SDCC(?)

2. bug in C-wrapper (I doubt it, I do not believe you publish wrong untestet code)

3. bug in SDCC or linker (possible, but then I have to debug it to a much lower level)

4. damaged PIC (but this would be the third, on two completely different boards)

    Can a PIC be destroyed by slight overvoltage (e.g. 6V)?

  But why does it work with other software then?

5. an error in my software.

    For me the most likely variant. But if so it's hard to find.

Today I will go back to really simple versions of software, just to check the hardware.

And verify that other software _really_ works.

And then step by step add new functions and variables.

Can I send you the hex-file that courses corruption? Just to verify if it is actually the hexfile

and not a general problem on my side (e.g. overvoltage, MIDI-IO of soundcard, Win98-problem)

   

Greetings Thomas

[TK.]

Hi Thomas,

I forgot to mention that I go the error string <sysex header> <device id> 0E 0B 00 7F. But you only decripted error messages up to 0A...

Why haven't you mentioned this before? ;-)

0B means MIDI buffer overrun. This can only happen on a programming error at the application side.

The current official release of MIOS Studio cannot handle such error messages correctly, therefore the confusion. I will ask Adam for a new beta release.

Potential programming problems which could cause this:

  - wrong use of MIOS_MIDI_* functions

  - overloaded interrupts

  - delays

I think that your .c file could be interesting

Best Regards, Thorsten.

[Thomas]

Hi Thorsten!

I'lll send you an email later, but a first question in public - maybe someone else has the same problem sometimes:

How can a progamming error cause remaining problems during upload?

I would unstand that a programm crashes during runtime.

(what quick'n'dirty c(++) programm never crashed with a lovely "segmentation fault" at first trial?)

I thought MIOS was destroyed because the copyright message was not printed correctly.

Maybe it's  earlier in the application than I thought, so that this message is overwritten by

application garbage very soon, too fast to notice.

The current official release of MIOS Studio cannot handle such error messages correctly, therefore the confusion.

I noticed that (it's getting very slowly when this happens, as well when it received a lot of messages sended by an open AIN-pin).

But this would not explain the destroyed MIOS. Even when MIOS Studio should send garbage, MIOS' (secondary) bootloader wouldn't flash it, would it?

I'm not completely sure but I think the problem was also when I used MidiOX for application upload.

(btw. I found the errorcode in the meantime in the MIOS-sources) 

[TK.]

If an error happens for any reason, the SysEx uploader has to retry, otherwise the old code block in combination with the new ones which have been uploaded successfully can lead to a random behaviour (!) once the invalid code will be executed. Worst case: flash write with bypassed protection

MIDI-Ox doesn't know about error responses, and cannot retry. Only MIOS Studio can handle this, but the current release not under all circumstances. This is a know issue, and partly fixed in the unreleased version. A complete fix would contain an additional upload procedure which ensures that code will never be executed so long all blocks have been uploaded successfully, but due to lack of Java knowledge (and time) I haven't implemented this.

(Discussion can be found in the MIOS Studio section)

How can a progamming error cause remaining problems during upload?

I don't know what happened before, therefore this general statement. Maybe something has gone wrong 10 uploads before? You are writing that you've tried an upload via MIDI-Ox. This is very critical in your case

I noticed that (it's getting very slowly when this happens, as well when it received a lot of messages sended by an open AIN-pin).

Do I see it correctly, that other MIDI messages than the SysEx streams by MIOS Studio are sent to the core? This cannot work under all circumstances, here a buffer overrun is very likely, since during a flash write USART cannot receive MIDI data.

So - if this is the case, the problem is not your program, but your system. It must be avoided, that any other MIDI sender is doing MIDI transfers during a code upload

Best Regards, Thorsten.

[audiocommander]

It could be really helpful if you post your code.

I think it's possible to have bad code that results in strange hex/syx files.

SDCC is not comparable to a long-time-tested compiler like GCC, so it may happen that there are compile errors that are not recognized, but deliver unpredictable results.

[Thomas]

Hallo Thorsten and Audiocommander!

I have a zip-file on my homepage

http://www.krachwerk.de/mb_thiele_c_20060524.zip

I normally hate it to publish unfinished, partly bad or experimental style code that is really written from brain to editor and therefor historically grown... ;)

I know there are a lot of uneffective or bad parts.

But there should be no error...(but it is *grrr*)

(Before you ask: no - the programm itself does not write to flash, the parts are comment out and are never called. Although they are there for experimental reasons. After these experiments the PIC was reprogrammed and loaded with new MIOS.)

[Thomas]

P.S: (@Thorsten) No other MIDI-event is send during upload.

[audiocommander]

Hi Thomas,

after taking a very (very) quick look: You're sending a lot of sysEx commands as response to AINs (in the intercom classes) with different buffer sizes. This seems a bit suspicious, having in mind what Thorsten remarked.

I'm going to have a deeper look next week (when I've a bit more time) ;)

Regards,

Michael

[Thomas]

Hi audiocommander!

I do not...and I will not (that why I asked for a better place in the other thread, this will be buffered in future).

AIN_NotifyChange()

->element_handlePoti()

    -> MIOS_MIDI_BeginStream();

    -> MIOS_MIDI_TxBufferPut(0xbe);

    -> MIOS_MIDI_TxBufferPut(pin);

    -> MIOS_MIDI_TxBufferPut(value7bit);

    -> MIOS_MIDI_EndStream();

    -> display_printElement()

        ->MIOS_LCD_CursorSet(0x00);

        ->MIOS_LCD_PrintCString("Fad ");

->MIOS_LCD_PrintBCD2(number);

->MIOS_LCD_PrintChar('/');

->MIOS_LCD_PrintHex1(MIOS_MIDI_DeviceIDGet());

[audiocommander]

You're right, I'm sorry (mentioned it's been just a quick view).

But the point is: it's all in your hex-file:

Block 003000-0033FF allocated - Checksum: 4F

Block 003400-0037FF allocated - Checksum: 71

Block 003800-003BFF allocated - Checksum: 59

Block 003C00-003FFF allocated - Checksum: 36

Block 004000-0043FF allocated - Checksum: 2C

Block 004400-0047FF allocated - Checksum: 4B

Block 004800-004BFF allocated - Checksum: 4E

Block 004C00-004FFF allocated - Checksum: 6E

Block 005000-0053FF allocated - Checksum: 1E

Block 005400-0057FF allocated - Checksum: 2D

Block 005800-005BFF allocated - Checksum: 75

And if there is a buffer overflow or something unlogical compiled, you can't be sure, that any data executed is really the data you think it ought to be. That's the mean thing with it...

I'm focussing to "How can a progamming error cause remaining problems during upload?".

If I were you, I'd try it with a fresh project skeleton without all that unused overhead.

If you succeed with it, you can slowly put all things back you want to implement and check from time to time if it works or not.

I'm pretty sure, if you do only the basic stuff, there is no problem (you said you succeeded with precompiled applications).

[Thomas]

Hi!

Have you checked the code by uploading it?

I have another idea, because some years(?) ago I had a similar problem.

Does the PIC need much more energie while flashing?

So much that the voltage drops and the PIC resets during upload?

I think I have to check this, too.

Although all problems started after uploading the modified MIOS...

But correlation is not causality... 

[audiocommander]

Have you tried if it works with an unmodified MIOS?

If you changed MIOS and made experiments writing your configuration into Flash rather than onto a bankstick, it's likely your problems result from there...

Cheers, Michael

[Thomas]

The MIOS version doesn't matter!

And I had a little while ago a experience that uploading a precompiled applications did not work as well. After erasing the PIC and after I reprogramming. (each step with verification).

And length of code also correlations with complexity. It need not to be a wrong code but only a big code if I'm right.

But I haven't found the current consumtion during flashing in the datasheet yet.

I will test it on saturday, so we don't debug in the wrong direction.

Schönen Männertag noch. *prost*