moogah Posted August 26, 2006 Report Share Posted August 26, 2006 I was finishing up on some changes today and, somehow, I got this message while make-ing the file. Error[118] C:\ARCHIVE\MIOS\X0XSEQ\MAIN.ASM 666 : Overwriting previous address contents (7BFE)Error[118] C:\ARCHIVE\MIOS\X0XSEQ\MAIN.ASM 666 : Overwriting previous address contents (7BFF)From these lines in main.asm:;; ---[ ensure that BSL location won't be overwritten ]--- org 0x7bfe dw 0x0000 It's the "dw 0x0000" thats causing the error. At one point today I had a bunch of files that were in the wrong workspace (I'm using MPLAB) that I cleaned up. I don't know if this could be related, I doubt it is. Since I don't really know where to start troubleshooting this I've been working on the following warnings instead: Warning[203] C:\ARCHIVE\MIOS\X0XSEQ\MIDI_EVNT.INC 81 : Found opcode in column 1. (call) Warning[202] C:\ARCHIVE\MIOS\X0XSEQ\MIDI_EVNT.INC 84 : Argument out of range. Least significant bits used. From these lines that I've added to midi_evnt.inc: call MIOS_DOUT_PinSet1 ; Single level of accent shared by all instruments CheckCH movf MIDI_EVNT1, 0 ; Move note value to W to use ANDL* xorlw CH_NOTE ; value for CH (Note#20) EDIT: I got it, as I suspected they were stupid mistakes on my part. The "Found opcode in column 1" message meant exactly what it said. The CALL instruction needs to be in the second column. The "Argument out of range" message was caused by the fact that I was using xorlw with a file register as an argument. I should use xorwf instead. Properly formed this is what the code should look like: CheckCH movf MIDI_EVNT1, 0 ; Move note value to W to use ANDL* xorwf CH_NOTE, 0, 0 ; value for CH (Note#20) bnz CheckRS movf CH_PIN, 0, 0 ; if the result was 0 play CH call MIOS_DOUT_PinSet1 ; play CH, pin cleared elsewhere goto MIDI_EVNT_Send_Ax Quote Link to comment Share on other sites More sharing options...
moogah Posted August 27, 2006 Author Report Share Posted August 27, 2006 Allright, I think I've found something. This problem may have been there all along without me noticing it. I googled the error number and found this:http://www.siliconchip.com.au/cms/A_102355/article.htmlSnippet:To get the AIRFUEL.ASM file to assemble successfully in MPLAB, you need to disable case sensitivity. This setting is to be found under "Project -> Build Options" on the "MPASM Assembler" tab.That didn't solve the problem, but at least it's something.There is also this site which shows that the 118 error message can be related to the ORG instructionhttp://www.piclist.com/techref/microchip/gotchas.htmLooking further I found this, which begins to confirm my suspicion that the error really isn't importanthttp://list.picbasic.com/forum/messages/6851/6994.html?1077317427Even though I get an error, the build succeeds and my fuses are set as theyshould be. I have been doing this with no problems for a while. I got tiredof editing the INC files for each PIC and/or changing the configuration eachtime I compile, which can be 100's of times per day, as I make a lot ofmistakes, er, I mean, improvements. Can anyone see anything wrong with this?If so, then this reply is a question. If not, then this reply is an answer(to Alessandro). And then, finally this snippet from the same sources:You do get an error, however:"Error[118] H:\MPLABWORK\SAMPL.ASM 62 : Overwriting previous addresscontents (2007)"But the program compiles and runs fine. I asked Microchip about the error,they said to ignore it. I have been having too many issues with Microcodeand errors or warnings that stop compilation, that I've reluctantly goneback to just MPLAB when I'm ready to start programming chips. Unfortunatly I havn't found a way to force the linker to create a .hex file, so I can't really test this. Quote Link to comment Share on other sites More sharing options...
TK. Posted August 27, 2006 Report Share Posted August 27, 2006 ;; ---[ ensure that BSL location won't be overwritten ]---means: you are using an old release of MBSEQ which was working with MIOS < V1.9, where the bootloader was located at 0xfc00-0xffff.This code line was intented to produce a compiler error in order to prevent, that somebody tries to overwrite a memory range which cannot be overwritten anyhow.Solution: so long you are using MIOS V1.9 and Bootloader V1.2, you can remove this "protection".Better Solution: use MBSEQ V2.4b or c, where this protection already has been removed.Best Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
moogah Posted August 27, 2006 Author Report Share Posted August 27, 2006 Ahhhh..So I wasn't being very careful when I cleaned out my files this afternoon..Double checking, yes, indeed some of the mixed up files were from v2.4a.. including the version of main.asm I was assuming to be correct.Thank you TK :)Now, the real problem I have seems to be that my application is too big. the .hex is 54kb, which I figured would be allright, but while uploading it went well beyond 7c0000 . There are two sections of the program that I would look ar first, the one I really think is bad is the following code I used to init a bunch of variables, surely there is a better way than this: movlw 0x24 movf BD_NOTE movlw 0x25 movf SD_NOTE movlw 0x26 movf LT_NOTE movlw 0x27 movf MT_NOTE movlw 0x28 movf HT_NOTE movlw 0x29 movf CP_NOTE movlw 0x2a movf MA_NOTE movlw 0x2b movf RS_NOTE movlw 0x2c movf CB_NOTE movlw 0x2d movf CY_NOTE movlw 0x2e movf CH_NOTE movlw 0x2f movf OH_NOTE movlw 0x00 movf BD_PIN movlw 0x01 movf SD_PIN movlw 0x02 movf LT_PIN movlw 0x03 movf MT_PIN movlw 0x04 movf HT_PIN movlw 0x05 movf CP_PIN movlw 0x06 movf MA_PIN movlw 0x1a movf RS_PIN movlw 0x1b movf CB_PIN movlw 0x1c movf CY_PIN movlw 0x1e movf CH_PIN movlw 0x1f movf OH_PINI inserted that into the begining of USER_Init just to keep things simple... but it's rather ugly....... so I'm a java programmer with 2 gigs of RAM on my PC.. what of it ;)it's just about time for bed now.. I'll get back to work on this tommorow.EDIT: I just checked the filesize, it's 55,026 bytes. I didn't find mention of the available application space, but I'm sure it's out there. Tommorow. Quote Link to comment Share on other sites More sharing options...
TK. Posted August 27, 2006 Report Share Posted August 27, 2006 Well, you are touching the memory boundary, thats the issue I had many times before, each time I wanted to add new features I had to optimize the code in order to free some bytes. In the meantime, the MBSEQ V2 has been optimized so often, that I would say, it doesn't make sense - especially for a programmer newbie - to work on this.The memory map can be found in main.lst (at the bottom)However, in general I strongly recomment the use of a PIC18F4620, and the use of the MBSEQ V3 firmware. This firmware has so many new features you really need for a good drum machine (e.g. 3 assignable trigger layers - e.g. for gate/accent/roll, 32 steps per track, tracks can be played at up to 96 ppqn, all tracks in RAM, cache mechanism for best performance, track direction progression parameters, more randomness, MIDI/AOUT port routing), that I don't understand, why you are still considering to extend MBSEQ V2.The only thing you would have to do is to overwork the menu screens, so that they are working with a 2x16 LCD.For this I assume an effort of about 3 months for somebody who hasn't worked with assembly code before.Btw.: here the current changelog http://www.ucapps.de/tmp/mbseqv3_changelog.txtBest Regards, Thorsten. Quote Link to comment Share on other sites More sharing options...
moogah Posted August 27, 2006 Author Report Share Posted August 27, 2006 Thank you for checking in TK, as usual one of your posts equals several hours of troubleshooting :)I'm planning on basing this sequencer on V3, but I really need to get alot of testing done ASAP so I've been using v2 as a shell. The Stuff I need to test isn't going to change much, although how I handle the interface will. Getting an LCD into a regular size case is really going to be a challenge, I wasn't planning on having such a complete application so I kinda screwed myself in that reguard and I don't think I will reccomend people use one in the "default" configuration as it may complicate the build process (people are already going to have alot to deal with). As you say the features your adding to V3 are very powerful in the context of a drum sequencer :) I'm also planning on making the needed changes to V3 using C instead of assembler since I'm much more familiar with the language.In good news, baby took her first 16 steps today! I had to axe alot of my code and then temporarily remove the humanize features to get everything to fit on the PIC, but she's ticking away now. All the sounds trigger just like they should ;D 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.