I done Broke'd it!

MIOS programming (Assembler)
1

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
2

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.html

Snippet:

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 instruction

http://www.piclist.com/techref/microchip/gotchas.htm

Looking further I found this, which begins to confirm my suspicion that the error really isn’t important

http://list.picbasic.com/forum/messages/6851/6994.html?1077317427

Even though I get an error, the build succeeds and my fuses are set as they

should be. I have been doing this with no problems for a while. I got tired

of editing the INC files for each PIC and/or changing the configuration each

time I compile, which can be 100’s of times per day, as I make a lot of

mistakes, 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 address

contents (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 Microcode

and errors or warnings that stop compilation, that I’ve reluctantly gone

back 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. 

3

;; —[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.

4

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 :slight_smile:

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_PIN

I 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 :wink:

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.

5

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.txt

Best Regards, Thorsten.

6

Thank you for checking in TK, as usual one of your posts equals several hours of troubleshooting  :slight_smile:

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