dwestbury Posted March 17, 2020 Report Share Posted March 17, 2020 (edited) 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 Edited March 17, 2020 by dwestbury Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 http://www.ucapps.de/mios_download.html under troubleshooting change id... 1 Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 (edited) 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 'https://gputils.svn.sourceforge.net/svnroot/gputils'] [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! Edited March 17, 2020 by dwestbury Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 (edited) 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... Edited March 17, 2020 by dwestbury Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 (edited) 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 Edited March 17, 2020 by Noise-Generator 1 Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 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.asm iic_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.asm clean: rm -f *.cod *.lst *.err cleanall: clean rm -f *.hex Appreciate your patience if you've made it this far! ;-) Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 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 1 Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 (edited) 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...)? Edited March 17, 2020 by dwestbury Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 (edited) 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 ;-) Edited March 17, 2020 by dwestbury Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 (edited) IPE PicKit programmer Edited March 17, 2020 by Noise-Generator Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 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! Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 17, 2020 Author Report Share Posted March 17, 2020 (edited) 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 @Noise-Generator 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.... Edited March 18, 2020 by dwestbury Quote Link to comment Share on other sites More sharing options...
Noise-Generator Posted March 17, 2020 Report Share Posted March 17, 2020 No problem, glad to see it alive! 1 Quote Link to comment Share on other sites More sharing options...
dwestbury Posted March 22, 2020 Author Report Share Posted March 22, 2020 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... http://midibox.org/forums/topic/21261-pic-programming-question/?do=findComment&comment=186267 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.