bootloader and mios upload

[Shum]

Hi,

I have built the midibox64 core based on the new pic18f452 chip. To test if the core works, I pluged in my pic16f877 programmed with the old firmware, the LCD came to live and it works. This confirms the the core is ok. I burnt the bootloader_v1_2_pic18f452.hex into the pic18f452 using the MBHP burner without problem. The core sends out an upload request after power on. However when I upload the mios_v1_9_pic18f452.hex through the miosstudio, it somehow receives unexpected mios sysex message from the core and stops after awhile. I re-burnt the bootloader and uploaded the mios again, the problem ancountered. I am at a lost grateful someone can help, please

Shum

[T.K]

Sidenote: I already tried to help Shum via email, but without much success.

So - if anybody else has an idea?

Best Regards, Thorsten.

[stryd_one]

Crikey if TK couldn’t fix it I don’t stand much chance but I’ll try…

Do you have an example of the unexpected sysex sent by the core during upload? What does the LCD do during all this?

I’d be looking at the MIDI Interface and connections, or maybe power, just to hazard a guess…

[audiocommander]

Crikey if TK couldn’t fix it I don’t stand much chance but I’ll try…

yeah, agree

I would try these two most obvious steps first:

• uploading as .syx via another program

• another MIDI device and/or driver update? There are quite a number of MIDI devices having trouble transmitting sysEx properly (I tried a Hercules FW card last week and got a reproduceable kernel panic when transmitting a syx-file to my core  :o )

rgds, Michael

[stryd_one]

yeah, agree

I would try these two most obvious steps first:

• uploading as .syx via another program

• another MIDI device and/or driver update? There are quite a number of MIDI devices having trouble transmitting sysEx properly

Oh yeh thanks very much for the vote of confidence, buddy ;D

Yeh I was thinking MIDI-OX etc…

And also wondering if it’s another one of those evil USB interfaces… But I was trying not to make a speech about USB again I thought that the incoming messages might hint at the location of the fault, either that the messages were normal, with some missing/corrupt bytes, like a bad solder joint on the midi connector on core; or random, like a cable/connector fault; or totally corrupt, like an interface/driver thing…

Something I should add:

I pluged in my pic16f877 programmed with the old firmware, the LCD came to live and it works. This confirms the the core is ok

Uhm, no it doesn’t. It proves that the LCD works. You could have a bad solder joint on the midi interface and that wouldn’t cause any problems there.

Hey, you did change the crystal over when you put in the PIC18 right?

[Shum]

Hi Thersten,

Thanks a lot for your help through the email. I have taken too much of your time already so I come to the forum to seek assistance. The core I built is based on MBHP CORE V2b © T.Klose 2002-06-23. Initially I used the pic16f877-20 with the old midibox64 firmware to control the B4 synth. However, I am trying to migrate to the new pic with mios as it provides more memory and features. The problem that I am having is similar to the one posted by Digispunk. The core with the pic18f452 is with the bootloader burnt in and it sends out uploading request every 2 seconds. This seems that the core is functioning (LCD blank). However, I have problem uploading mios like what was mentioned by Digispunk. I do not know where I have gone wrong. The following was what I did;

1. Burnt bootloader V1_2 (new pic)

2. Plug pic in core and powed up - core sends out request message

3. Power off core. Open up Miso Studio and load mios v_1_9 hex file

4. Routed midi in/out accordingly

5. Checked the wait for uploading request box

6. Checked the with feedback from core

7. Click start on the Miso Studio

8. power up the core

The result - Mios Studio receives sysx date with check sum without error for few blocks. Thereafter Mios Studio receives enexpected mios sysex message as such - F0 F0 F0 F0 7E F0 00 01, expected is 00 00 7E 40 00. After 3 times the upload stops. Thanks

Shum

[T.K]

Something that is new to me is, that some blocks can be uploaded correctly.

Does this happen randomly? Or are these always the same blocks?

Could it be a problem with the power supply? The PIC18F452 consumes (a little bit) more, since it runs at 40 MHz… especially during flash programming. Means: during code upload

In general multiple “F0 F0 F0 F0” indicate, that the core has been reset several times.

This can happen on:

  - no enough power

  - USART receive overrun error (unlikely so long the PC interface is working)

  - USART frame error on received bytes (can happen if the PC interface is running at a slightly incorrect baudrate)

The rest of the bytes behind F0 which don’t match with a common upload request could be related to a driver quirk on the PC MIDI interface. But it can be ignored, because the previous bytes where already wrong

Best Regards, Thorsten.

[T.K]

Are all the jumpers at the programming port J3 closed?

Best Regards, Thorsten.

[stryd_one]

3. Power off core. Open up Miso Studio

Japanese MIDIBox Soup. Tasty.

[Shum]

Hi Thorsten,

Thanks for the advice. Yes all the links of J3 are closed. How can I tell if the PC interface is running at incorrect baudrate. For information, I tried uploading the MIOS from different PC but also failed. Is it likely that the problem is in the conversion of the HEX to SYX file? Thorsten could you send me the MIOS syx file through email so that I can try it on the core again. Tell me, if it were the power supply (12v at 500 mA) or the USART problem, should I not have problem with the old pic16f877? Think I will leave this project aside to clear my mind. I will start afresh to check all the steps I had taken to troubleshoot. By the way Stryd_one, I miss typed the word MIOS as MISO. Perhaps I have had to much of Japanese food recently.

Thanks for the help everyone and with best regards.

Shum

[stryd_one]

By the way Stryd_one, I miss typed the word MIOS as MISO. Perhaps I have had to much of Japanese food recently.

There is no such thing as too much Japanese food

[Shum]

Hi Thorsten and Michael,

I started from scratch again and burnt the bootloder v1_2_pic18542 into the pic. Plug it into the core and power on and I got the  upload request.

I reconvert the MIOS hex to syx, at the end of the conversion there is an error message that says “you are trying to overwrite the Bootloader range! If you are using a 64k pic device add -mem_64k!” If I upload the MIOS it would overwrite the bootloader is’nt it.

Is there something I must do first before converting MIOS hex to syx?  ???

Ps I have the images but how I can attach them to this posting?

Hi Stry_one I take it that you are a Japanese food fan!

Regards

Shum

[audiocommander]

Yes. It’s in the hex2syx.pl file:

# SYNTAX:
hex2syx.pl <hex-file>.hex [<-device_id 0x..>] [<-bankstick <0-7>] [-os_upload] [-force] [<-debug>]

In other words: you need to type [tt]hex2syx.pl myfile.hex -os_upload[/tt]

That’s a precaution thing to prevent accidential overwriting of parts of the system!

Maybe we should think about mentioning this in the README.txt of mios_download.

I’d be very interested to hear the MIOSStudio-version you used for trying to upload the hex-file.

If you succeed now with sending the .syx-file (and I think chances are very high :)), it might be likely that there’s an error in MIOSStudio (because this would be the second case with this specific upgrade error)…

please keep us up to date -

best regards,

Michael

[Shum]

Hi Michael,

I have not uploaded the MIOS to the core yet. I want to be sure the MIOS.syx file is converted correctly first.  I typed in the following syntax “perl hex2syx.pl mios_v1_9_pic18f452.hex -os_upload” to start the conversion. As I mentioned before, at the end of the conversion, I got an error message warning me that I am trying to overwrite the Bootloader range! That means to say I cannot use the converted MIOS.syx file for the upload. If so how do I overcome this error?  ??? BTW how do I insert images on this posting/reply

Thanks

Regards

Shum

[audiocommander]

perl hex2syx.pl mios_v1_9_pic18f452.hex -os_upload

I got an error message warning me that I am trying to overwrite the Bootloader range

just add “-force” to get a valid .syx-file:

[tt]./hex2syx.pl mios_v1_9_pic18f452.hex -os_upload -force[/tt]

[tt]Block 000400-0007FF allocated - Checksum: 4E

Block 000800-000BFF allocated - Checksum: 3A

Block 000C00-000FFF allocated - Checksum: 23

Block 001000-0013FF allocated - Checksum: 40

Block 001400-0017FF allocated - Checksum: 6A

Block 001800-001BFF allocated - Checksum: 5D

Block 001C00-001FFF allocated - Checksum: 35

Block 002000-0023FF allocated - Checksum: 51

Block 002400-0027FF allocated - Checksum: 11

Block 002800-002BFF allocated - Checksum: 7F

Block 002C00-002FFF allocated - Checksum: 42

Block 003000-0033FF allocated - Checksum: 2E

Block 007C00-007FFF allocated - Checksum: 51[/tt]

BTW how do I insert images on this posting/reply

If you reply, just open up “Additional Options” below the reply text field, there you can attach a pic.

Or upload your pic at imageshack or similar webservice and link it by ‘img’ and ‘/img’ enclosed in brackets

[T.K]

Hi Shum,

I guess that you are still not using the most recent hex2syx.pl script, which is part of the mios_v1_9_src package, and located in the tools/ directory (I wrote you about this some days ago, but I never got an answer, if you really tried it).

The old script doesn’t know about the changed memory ranges.

So, with the new script you will be able to convert the .hex when you add the “-os_upload”

AC: I don’t want to make the usage of this script too much public, since it is too difficult to handle (as you can see…) and the unidirectional upload without checking the error codes is too dangerous. It’s better to have a flawless working MIOS Studio. So, if this tool (or Java) is the reason why the code upload doesn’t work at Shum’s PC(s), then we should find out, why

But before making such hypotheses, it would be an important input from Shum’s side, if the upload is working with MIDI-Ox

Shum: here a direct link to the source package:

http://www.ucapps.de/mios/mios_v1_9_src.zip

you can find hex2syx.pl in the tools/ directory

Best Regards, Thorsten.

[audiocommander]

I don’t want to make the usage of this script too much public, since it is too difficult to handle (as you can see…)

I see

I’m always uploading with SysEx-Librarian because it’s so comfortable, but of course you’re right about the POV of a Windows-Machine (I forget that sometimes )

I’ve sent shum the .syx-files I used for my Core(s).

I’m very interested to see if they will work being uploaded with MIDI-Ox…

Best Regards, Michael

[Shum]

Hi Michael,

I tried to upload the MIOS you sent me to the core via the syxexBox, and I got the result  as shown in the attach pics.

[Shum]

Hi Thorsten,

I am sorry that I did not reply to the email. I did use the script from the Mios V1-9_SCR. I use the main.asm file to generate the hex file using the MPLAB. The I uploaded it to the core, however it failed to work as well. Since I have tried all the tools to upload MIOS, including the one from the SCR package and fail, it was too embarrasing to mentioned it. I looked through troubshooting guide and those from the forum postings I got the feeling the my SB AWE64 sound card/driver may be the problem (though it work on the old pic16f877 - midibox64 and also on syx transfer of soundbanks on my WX5 and VL70M). I have the following snap shorts from midiox - the result of the MIOS upload. I may have to buy another sound card, do you have any suggestions what I should buy or should I build the USB-Midi module?

Thanks

Regards

Shum

[stryd_one]

Incomplete sysex bytes and resets, sounds like it still has problems with power or midi…

Anyone have a list of error codes? What’s 0B 01? Buggered if I can be bothered trawling source code right now