I managed to burn the setup_mb6582.hex to my PIC18F4685 using MIOS Studio (2.4.8) from my Mac, but somehow I set the Core ID wrong.
MIOS communicates with the PIC perfectly on Device ID 2, but I can’t boot properly or use my control surface this way!
I’ve scoured through a bunch of the MIOS material in the Wiki and the Forums, but I can’t seem to follow the steps (sorry, newbie brain is trying!).
Many thanks for any assistance…
Cheers
3 hours ago, Noise-Generator said:
http://www.ucapps.de/mios_download.html
under troubleshooting
change id…
Yep followed that one… Still stuck, but let me explain…
The readme for ‘change_id_v19g’ says…
Quote
Required steps for a proper ID initialization:
o ensure that the MIOS bootloader has already been programmed into
the PIC. You should see an upload request after power-on
(see also: http://www.ucapps.de/howto_debug_midi.html)) [DW - I have one PIC with working bootloader, but I can’t seem to make any others?]o upload the most recent MIOS version like described under:
http://www.ucapps.de/mios_bootstrap.html [DW - I’m able to do this in MIOS]o open the Makefile (or make.bat file) and change the ID settings for your needs [DW - Assume this references ‘makefile.orig’, since ‘makefile’ has almost no content?]
o build a new .hex file, see also
http://www.ucapps.de/howto_tools_gpasm.html[DW - Can’t find the source code files - SVN Error: Unable to connect to a repository at URL ‘gputils download | SourceForge.net’]
[DW - the gpasm wiki says “you probably need a PC to burn the MBHP loader into the PIC” - However, I’m on a Mac.]
[DW - Q: does anyone have a version of gpasm that’s been compiled and tested for OSX Catalina 10.15.3?]
[DW - Q: is there a way to assemble the hex file using MLPAB X IDE?]
Thanks much!
Making progress…
I installed MacPorts, which enabled me to find and compile working versions of sdcc and gpasm for Mac OSX Catalina 10.15.3.
However, before I attempted to run ‘change id’, I thought I would first try to follow the MIOS Bootstrap guide (http://www.ucapps.de/mios_bootstrap_experts.html).
I hoped that a fresh PIC with the bootloader images (‘bootloader_v1_2b_pic18f4685.hex’ & ‘mios8_v1_9h_pic18f4685.hex’) would default to Device ID 0, which should be detectable by MIOS Studio.
But unfortunately, MIOS 2.4.9 doesn’t see my new PIC on any of the selectable Device IDs?
Does this means I need to tweak Device IDs (and other settings) in the hex files, even for freshly burned PICs?
Quote
Boot options
The bootstrap loader has to know about two important parameters: the MIDI device ID, which should be unique number in a chain of multiple MIDIboxes, and the baudrate. It can be chosen between the common MIDI baudrate (31250) and the rate used by the MIDIbox-to-COM interface (38400).
A third parameter allows to define the connected LCD type, so that MIOS is able to select the appropriate driver before printing a message on screen. Currently character displays (1x8, 1x16, 2x16, 2x20, 2x40, 4x16, 4x40) and KS0108-based graphical LCDs are supported, other GLCD types require a special driver which is embedded into the application.The boot options are located in the PIC ID header. The SysEx device ID is located in bitfield ID[57-63], the UART mode in ID[55], the LCD type in ID[48..51], the MBHP_IIC_MIDI address for MIDI Out redirection in ID[40..47]. Here are some setup examples:
- ID = 0000000000000000 : common MIDI interface, character LCD, Device ID 0x00
- ID = 0000000000000001 : common MIDI interface, character LCD, Device ID 0x01 (e.g. for a MBSID Slave #1")
- ID = 0000000000000002 : common MIDI interface, character LCD, Device ID 0x01 (e.g. for a MBSID Slave #2")
- ID = 0000000000000003 : common MIDI interface, character LCD, Device ID 0x01 (e.g. for a MBSID Slave #3")
- ID = 0000000000000142 : MIDIbox-to-COM interface, character LCD
- ID = 0000000000001000 : common MIDI interface, graphical LCD (KS0108)
- ID = 0000000000007000 : common MIDI interface, custom LCD driver (see also these examples)
- ID = 0000000000120000 : common MIDI interface, redirect MIDI Out stream to MBHP_IIC_MIDI with address 0x12
SmashTV wrote a nice online user interface to select the PIC ID values! [DW - this link is unfortunately dead now]
Unfortunately, “modern” PIC programmers (like for PICKIT2) don’t allow to change the ID from the GUI anymore.
Therefore the proposed solution (aside from .hex file hacking) is the usage of the change_id application, which allows to change these parameters via MIDI.
Thanks…
No, you don’t need to compile stuff, you should change the id via the change-id app but I don’t have in mind how but I did make that in past. There must be a much easier way.
Btw, you find all Information at ->ucapps—>sid module—>walktrough
Apologies for spamming the forums today as I iteratively struggle my way through this process…
I’m attempting to run ‘change id’ now, to generate a new hex file with the correct Device ID, but i’m a bit confused about what to edit in the ‘Makefile.orig’
Quote
$Id: Makefile 324 2008-05-03 20:25:44Z tk $
define the processor here
PROCESSOR = 18f452 [DW - Assume I should change this to 18f4685 ?]
default flags to GPASM here
GPASM_FLAGS = [DW - Is anything needed here?]
include pathes (more will be added by asm_only.mk files)
GPASM_INCLUDE = [DW - There are two path includes further below, is anything explicitly needed here?]
# optional defines that should be passed to GPASM
GPASM_DEFINES = [DW - Is anything needed here?]default rule that defines the .hex files which should be created
note: always require a “cleanall”, since dependencies (e.g. on .h and .inc files) are not properly declared
all: cleanall main.hex device_id_00.hex device_id_01.hex device_id_02.hex device_id_03.hex iic_midi_10.hex iic_midi_12.hex iic_midi_14.hex iic_midi_16.hex
include the asm_only.mk file
include $(MIOS_PATH)/include/makefile/asm_only.mk [DW - Currently, my shell environment doesn’t include MIOS_PATH, is this needed or should I just replace with an explicit text folder path?]
include application specific LCD driver (dummy driver by default)
include $(MIOS_PATH)/modules/app_lcd/dummy/app_lcd.mk
additional make rules to assemble variants with predefined ID
device_id_00.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DMIOS_DEVICE_ID=0x00 -o device_id_00.hex main.asm [DW - Assume this is the only command I need to force a Device ID 0 into my hex file?]
device_id_01.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DMIOS_DEVICE_ID=0x01 -o device_id_01.hex main.asm
device_id_02.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DMIOS_DEVICE_ID=0x02 -o device_id_02.hex main.asm
device_id_03.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DMIOS_DEVICE_ID=0x03 -o device_id_03.hex main.asmiic_midi_10.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DIIC_MIDI_ADDR=0x10 -o iic_midi_10.hex main.asm
iic_midi_12.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DIIC_MIDI_ADDR=0x12 -o iic_midi_12.hex main.asm
iic_midi_14.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DIIC_MIDI_ADDR=0x14 -o iic_midi_14.hex main.asm
iic_midi_16.hex: main.asm
gpasm $(GPASM_FLAGS) $(GPASM_INCLUDE) $(GPASM_DEFINES) -DIIC_MIDI_ADDR=0x16 -o iic_midi_16.hex main.asmclean:
rm -f *.cod *.lst *.errcleanall: clean
rm -f *.hex
Appreciate your patience if you’ve made it this far! 
I checked the zip, package, there are 4 files called device-id-00.hex (00- to 04)
So you just take the hex what fits for you
Just now, Noise-Generator said:
I checked the zip, package, there are 4 files called device-id-00.hex (00- to 04)
So you just take the hex what fits for you
I thought that change id was actually using gpasm to merge multiple hex files together (e.g., main.hex + device_id_00.hex + iic_midi_10.hex, etc…)?
No, it’s just as easy as it is
But you came far to get the stuff running to compile with your Mac.
What I can’t understand is why you don’t have id 0 by default.
Just now, Noise-Generator said:
No, it’s just as easy as it is
But you came far to get the stuff running to compile with your Mac.
What I can’t understand is why you don’t have id 0 by default.
First off, thanks for riding this rollercoaster with me. In the end I’m sure it’s a case of “user error” ;-)
I think I need to burn three hex files to get the proper bootloader (‘bootloader_v1_2b_pic18f4685.hex’, ‘mios8_v1_9h_pic18f4685.hex’ and ‘device_id_00.hex’).
The default behavior of the IDE is to erase the PIC before writing, so I either need to figure our how to turn that option off or somehow combine all three files together and write once?
Hope I’m pointing in the right direction now
Ah, no.
As I said, you don’t need to compile. You digged to deep. It’s good for your knowledge but not in the case do get the stuff running immediatly.
First, flash Bootloader with PicKit Programmer (IPE not IDE should be inside the pack with the IDE, however by google I just get this result) if you can handle it with IDE, never mind. But you just need the easy IPE with which you can load hex files.)
bootloader_v1_2b_pic18f4685.hex, right
First choose device Family 18fxxxx
I don’t really know if there is a way to give ids, I think its in the hex and default 00
Than
open MIOS, connect to your PIC via Midi, error message, right
load mios8_v1_9h_pic18f4685.hex
Should upload after some seconds, if not, turn power off and on
Should upload
Than
you get no error message, MIOS recognized or something
upload setupmb6582.hex or however it’s called correctly
do this with every PIC and change their ids
No problem to ask, I also had and will have this times where I’m stuck or don’t understand correctly.
Just now, Noise-Generator said:
Ah, no.
As I said, you don’t need to compile. You digged to deep. It’s good for your knowledge but not in the case do get the stuff running immediatly.
First, flash Bootloader with PicKit Programmer (IPE not IDE should be inside the pack with the IDE, however by google I just get this result) if you can handle it with IDE, never mind. But you just need the easy IPE with which you can load hex files.)
bootloader_v1_2b_pic18f4685.hex, right
I wrote bootloader_v1_2b_pic18f4685.hex to a different PIC (using the IDE) and was finally able to get MIOS to recognize it as Device 0.
I was also able to use MIOS to write setup_mb6582.hex - Progress!
However, my control surface and LCD still aren’t working? - _ Torture! _
OK, OK, OK… After several days of mind bending torture, I finally figured it out…
And it’s actually extremely easy… DOH!
Step 1: Write bootloader_v1_2b_pic18f4685.hex to the PIC using your favorite Microchip utility (I used MPLAB X IDE, others like IPE Pickit Programmer, etc.).
Step 2: Load up MIOS (I’m using v2.4.9). It should detect the PIC as Device 0 (default behavior), then you can write mios8_v1_9h_pic18f4685.hex
(both hex files above come from ‘mios_v1_9h.zip’ available in the Operating System section of the downloads page: http://www.ucapps.de/mios_download.html)
Step 3: If all goes well, your LCD will show " READY." (a cute throwback to the old C64 days), then finally you can write setup_mb6582.hex
Step 4: When your system finishes rebooting, it should be ready for control surface testing…
Big thanks to for keeping me sane as I careened off one cliff and onto another…
Wheew…
Special note :
I wasted a ton of trial-and-error-time time before I finally realized that I had one bad PIC in my batch.
Newbie brain + fat fingers mean, I probably installed it backwards into the chip writer one too many times or maybe I exceeded its natural rewrite threshold, etc.
I was always able to write the bootloader to it, but MIOS would never detect it. I didn’t have enough experience with the process to realize that I was working with a dud…
In hindsight, a telltale sign to remember is that every LED on the control surface was lit up when this PIC was in the Master Core 1 socket.
This is what you would see if you powered up with no PIC in the Master Core 1 socket.
With a properly functioning PIC, you won’t see any active lights on the control surface until the setup_mb6572.hex is installed…
Mentally filed under lessons learned…
No problem, glad to see it alive!
Connecting two posts that inevitably crossed into the same territory…
After completing the steps above to create the Master Core Module, I stumbled around a bit more to understand how to change device ID’s for the slave modules…
All the required steps are outlined here…
