Trouble flashing merger from bootloader

Testing/Troubleshooting
1

I’ve turned an old core from SmashTV (CORE R3) with a 18F452 into a midi merger.

The PIC has a sticker from SmashTV that says MIOS_BOOTRAP_V1_1B.

In mios studio the core responds to query:

Operating System: MIOS8

Board: MBHP_CORE or similar

Core Family: PIC18F

Application is up & running!

I have successfully upgraded mios by uploading mios_v1_9g_pic18f452.hex

But when I try to upload by selecting midimerger_v1_5\midimerger_pic18f_with_bootloader.hex it shows:

Reading midimerger_pic18f_with_bootloader.hex

midimerger_pic18f_with_bootloader.hex contains 830 bytes (5 blocks).

Range 0x00000000-0x00002fff (12288 bytes) - MIOS8 area

Range 0x00003000-0x000007ff (4294957056 bytes) - PIC Flash

Range 0x00300000-0x003000ff (256 bytes) - LPC17 Flash

Press start button to begin upload.

When I click “start” I get:

Reading midimerger_pic18f_with_bootloader.hex

Trying to contact the core…

midimerger_pic18f_with_bootloader.hex contains 830 bytes (5 blocks).

Range 0x00000000-0x00002fff (12288 bytes) - MIOS8 area

Range 0x00003000-0x000007ff (4294957056 bytes) - PIC Flash

Range 0x00300000-0x003000ff (256 bytes) - LPC17 Flash

Hex file contains invalid ranges for MIOS8!

Unfortunately I don’t have a PIC Burner. Is there a way I can update the Bootloader with MIOS Studio? (assuming that is the problem.)

2

From uCapps:

PIC18F452 based: this is another variant for people who own a spare PIC18F452. There are two different .hex files: one which can be burned directly into the PIC, and another which can be downloaded via MIOS Bootstrap Loader the same way like you would do with MIOS

So I guess you just have to download the correct .hex file, the one that doesn’t include the bootloader.

3

So I guess you just have to download the correct .hex file, the one that doesn’t include the bootloader.

Not really sure what you mean. I’m using MIOS Studio (I dont have a burner). From MS I’ve attempted to flash both the “with” and “without” bootloader hex files. In both cases MS shows similar error messages reproduced above.

I think my problem may a be that I have an earlier (somewhat incompatible bootloader 1.1B) in the chip.

4

Well, as far as I know the Merger doesn’t run on MIOS. You have to treat the .hex file (the one without the bootloader) as the MIOS image, and start flashing it using SysEx during the 2 second windows during boot.

Again from uCapps:

In fact two bootstrap loaders are provided by MIOS: the primary and the secondary loader:

•The primary loader gets active immediately after power-on for about two seconds. During this time the loader waits for a SysEx command which initiates a flash write. If this command is not received, the loader deactivates itself and MIOS will be started.

•The secondary loader gets active after MIOS has been booted and the application is running. In difference to the primary loader, the secondary doesn’t allow to overwrite the memory allocated by the operating system. This kind of protection saves you from destroying MIOS if your application overlaps the system area by mistake.

So my guess would be that you are trying to upload the .hex file after MIOS has already started, and it prevents writing to that particular section of memory.

In addition I found this:

MIOS V1.9 â—¦ the bootloader location has been moved from 0x7c00-0x7fff to 0x0000-0x0400. This frees the upper 1k block for applications, and equates the memory allocation between PIC18F452, PIC18F4620 and future PIC devices.

This makes me believe that not much has changed between bootloader 1.1 and 1.2, only the location in the memory is different. It might still be that I’m overlooking something as I’m not really proficient with this stuff yet, but I hope it gives you some pointers.

5

We’ve multiple problems:

  • MIOS Studio 2 doesn’t work correctly with bootloader v1.1 (which has been replaced by v1.2 more than 6 years ago…)

  • midimerger_pic18f_with_bootloader.hex can only be handled by bootloader v1.2

  • the upgrade from v1.1 to v1.2 is cumbersome and error prone, multiple people already crashed their PIC so that it had to be flashed again with a PIC programmer

  • it seems that MIOS Studio 2 has also problems to parse the .hex file

Idea: if I’m not wrong, you should be able to upload the midimerger_pic18f_without_bootloader.hex file with MIOS Studio 1:

http://miosstudio.midibox.org/index_v1.html

Background: bootloader v1.1 is located between 0x7c00..0x7fff and starts the application at 0x0000

in midimerger_pic18f_without_bootloader.hex the app is located at this address

and MIOS Studio 1 is able to communicate with bootloader v1.1

Best Regards, Thorsten.

6

O.k, (after discovering MIOS Studio routing dialogue!:slight_smile:

Starting upload of midimerger_pic18f_without_bootloader.hex

Hex file contains code in MIOS range, forcing reboot for upload via 1st level bootloader!

The reboot request will lead to an error acknowledge, please ignore!

Waiting for upload request…

Received error code 01: Less bytes than expected have been received

This was an expected error - please ignore!

Received Upload Request

Sending block #1 00000000-000000FF

Received error code 05: Write access failed (invalid address range)

..

..

Sending block #1 00000000-000000FF

Received error code 05: Write access failed (invalid address range)

Aborting after 16 errors

7

So, your PIC is already running with bootloader v1.2?

Best Regards, Thorsten.

8

So, your PIC is already running with bootloader v1.2?

Is it possible that this happened when I flashed MIOS1.9g ?So if I am running with 1.2 now, then it is a bug in MIOS Studio 2.3 causing this?

[edit]I can confirm that the midi router 1.1c flashes fine with Mios Studio 2.3

[p.s] I am (still) unable to flash MidiMerger though.

9

O.k, I’ve set up the tools and can assemble midimerger_pic18f_with_bootloader.hex

Is there some transparent change I can to that will make it so that MIOS Studio parses the hex file o.k?