topic Re: macro call generating error A2381 & A1055 in CodeWarrior for MCU

macro call generating error A2381 & A1055

irob — Thu, 29 Oct 2020 09:20:59 GMT

Hey, guys, I'm currently trying to port over the assembly code from Freescale's USB 3D mouse project, "RD68HC08USB3DMSESW". This runs on the MC908JB8 microcontroller. The code was compiled under the CASM08 assembler by RAPID.

I created a new assembly project in CW 6.0. As you can imaging, there are a lot of syntax differences, mostly with directives.

The macro definitions are a bit different. I'm getting a puzzling error with most of the macros defined, A2381 and A1055. Here's the macro:

Code:

;* MACRO - copy #\1 to \2KMOV:   MACRO        lda     #\1        sta     \2        ENDM

The compiler gives me the A1055 here, complaining about the lda #\1 line.

Here's how it's called:

Code:

        KMOV    {1<b_IDLE},V_TRANSACT      ; device idle        clr     V_PROCESS                  ; reset processing status

This call gives me error A2381 on the macro instantiation.

What I'm not clear on yet is that syntax with the braces. Is the greater-than symbol some sort of bit relocation?

Thanks!

Re: macro call generating error A2381 & A1055

bigmac — Thu, 13 Dec 2007 03:49:56 GMT

Hello iRob,

I think at least part of your problem is the use of braces. CW expects to see parenthesis used instead. In fact, you should search all the assembly files for the presence of braces, and change them. With many fonts (including the ones I use for programming), it is extremely difficult to recognize the difference at a glance. { } ( ) This example uses Courier New font.

Another problem is that the left-shift operator in CW is << rather than <

KMOV (1<<b_IDLE),V_TRANSACT ; device idle

The expression within the parenthesis creates a mask value from the bit number represented by b_IDLE.

Regards,

Mac

Message Edited by bigmac on 2007-12-13 06:59 AM

Re: macro call generating error A2381 & A1055

irob — Thu, 13 Dec 2007 05:01:35 GMT

Thanks, BigMac! You've been a big help. Thank goodness for search & replace with regular expressions!

Still getting lots and lots of "warning, value truncated", but I'll continue to slug through them all.

Re: macro call generating error A2381 & A1055

irob — Thu, 13 Dec 2007 08:09:48 GMT

Hey Big Mac, would you care to take a look at this project? I've got it down to 107 errors, 150 warnings (maxed out).

I'm getting tons of "truncated byte" warnings, not sure why. I've got the MCU specific memory map ported over to CW's include file now.

Anyone else is invited to take a stab if they have the time.

Re: macro call generating error A2381 & A1055

peg — Thu, 13 Dec 2007 12:28:09 GMT

Hi Rob,

I did not take a look inside your zip, but...

Truncated byte is usually the assembler telling you you did 16-bit maths and it is going throw away the high byte of the result. Usually the programmers response is "see if I care"
Something like LDA #(address-SlightlySmallerAddress)

Re: macro call generating error A2381 & A1055

bigmac — Fri, 14 Dec 2007 21:42:04 GMT

Hello iRob,

Be aware that the CASM08 assembler provides absolute assembly, whereas CW defaults to relocatable assembly. The process of converting your project to be relocatable would actually require a lot of effort, setting up XDEFs and XREFs for all equates, variables and sub-routines. So I decided to stick with absolute assembly, and the sequence of INCLUDEs.

I have previously handled absolute assembly with CW, by running the assembler tool alone, without the IDE. When I initially assembled your code under this regime, I obtained 79 errors and 207 warnings. The following is an outline of the problems that I discovered - some are due to differences between CASM08 and CW assemblers.

Remove the line INCLUDE "JB1-EQU.H", since "derivative.inc" file is now used.
Many of the RAM variables require to reside at page 0. So the line ORG RAMStart is incorrect, it should be ORG Z_RAMStart.
Within an expression, the CW assembler does not like any whitespace either side of the operator (any operator). For example, VarA + VarB is invalid. The expression should be VarA+VarB. There are about 36 instances within a couple of the ASM files.
Instructions such as BRCLR that require to repeat until a bit flag becomes set often use a symbol to represent the PC value at the start of the current line (rather than use a label). For CW, the symbol is the asterisk. There are some instances where $ is present, which is valid for CASM08, but not CW.
The line INCLUDE "macro.inc" was present in two of the other INCLUDE files, as well as the primary file, resulting in duplicated macro definitions. Either remove the line from both secondary files, or use a conditional include to prevent multiple includes, i.e. surround the INCLUDE directive with IFNDEF and ENDIF directives, and add a distinctive label name within macro.inc, for example _MACROS_:
The file USB-MSE3.H is currently INCLUDEd at the very end of the primary file. This line must be moved to just prior to the start of the initialisation code, so the labels defined within will be known to the assembler, prior to their use within the primary code.

Following these corrections, there remained three errors only, for undeclared symbols. Once the correct MCU bit names were substitued, the code assembled without error. However, another major error would have prevented the code from operating correctly - the _Startup entry point was incorrectly placed. The RSP instruction will also need to be removed since you have initialised the stack to higher RAM. You will also need to check the time delay routines for the correct delay (because of different MCU, and probably different bus frequency).

Regards,

Mac

Message Edited by bigmac on 2007-12-15 12:46 AM

Re: macro call generating error A2381 & A1055

bigmac — Fri, 14 Dec 2007 22:56:36 GMT

Hello again iRob,

Continuing from my previous post . . .

After having successfully assembled the corrected source code using the stand-alone assembler tool, I then attempted to handle the same code using CW IDE, and its project structure. When I attempted to compile the primary file, some further errors and warnings occurred, but an attempt to make the project resulted in a vastly greater number of errors and warnings (assumed to be caused by the default relocatable issue).

Closer examination of the assembly errors revealed case inconsistency for some of the labels. Whereas the assembler alone ignores the case of the labels (as does CASM08), for assembly via the IDE, case is significant. This seems rather unusual - perhaps the IDE in fact uses a different assembler than the stand-alone tool.

The case inconsistency within the files also indicates to me an EXTREMELY SLOPPY programming technique, especially since mixed case labels seem to occur "willy-nilly" within the code. Perhaps I am ranting . . . but this code certainly does not have a clean and consistent layout IMHO.

Having made the further corrections, I was then able to compile without error, but not make the project. The compile produced the correct code size, but did not generate the required S19, and other output files. After some experimentation, I found I could make the project, provided I deleted the two secondary files, 8HID-PRO.asm and 8USB-ISR.asm, from the project structure. Of course, the files should remain within the source folder.

Perhaps others might advise of alternative ways of handling absolute assembly from within a CW project, that would allow editing of the secondary (include) files by the IDE.

Regards,

Mac

Re: macro call generating error A2381 & A1055

CompilerGuru — Fri, 14 Dec 2007 23:42:35 GMT

The ide is using the same, identical assembles as when you run it standalone.
But the behavior not to consider the case of labels is non default and has to be enabled.
When using just the assembler in absolute assembly mode, then that's all it needs.
When using the linker, the linker would also need to be told to ignore the case of identifiers, I think it also has an option to do that.
Having multiple *.asm files in the ide does not work if you are building an absolute assembly file, then only one *.asm file has to build all the files, other *.asm files can exist but either not in the same build target, or not in the project at all.

Daniel

Re: macro call generating error A2381 & A1055

bigmac — Sat, 15 Dec 2007 01:13:24 GMT

Hello,

I changed the extension of the secondary files from *.asm to *.inc, and the make process now seems to work fine. The extension of the macro.asm file doesn't seem to matter, but this was also changed for consistency. I assume that any extension, except *.asm, may be used for the secondary files.

Regards,

Mac

Re: macro call generating error A2381 & A1055

irob — Sat, 15 Dec 2007 02:09:41 GMT

Yikes, yikes! Did I ever underestimate the difficulty level?! Thanks, BigMac for your help!

I looked at your steps but didn't find any spaces between operators. Hmm. But after your list, I'm down to 70 errors, 106 warnings. Now this is with using the Make option in CW.

I think at this point, this is a wasted effort. I'm backing up and trying again with some of Freescale's sample C code.

Thanks, guys.

Re: macro call generating error A2381 & A1055

irob — Thu, 29 Oct 2020 09:21:00 GMT

bigmac wrote:

I changed the extension of the secondary files from *.asm to *.inc, and the make process now seems to work fine.

Ahh, nice find. My project is now down to 9 errors, 6 warnings. Getting better! But, this is interesting, now I got a series of "A2401: Complex relocatable expression not supported" errors. Here's an example from 8HID-PRO.inc, error on line 799:

Code:

799:    lda     #(DEVICE_DESC/256)      ; make LONG_IDX routine        sta     V_Opd_H                 ; point to DEVICE_DESC queue

Re: macro call generating error A2381 & A1055

bigmac — Sat, 15 Dec 2007 10:39:47 GMT

Hello iRob,

While I did not receive the same error message, the label DEVICE_DESC was one of about three labels affected by item 6 on my previous list. The error should not occur if the value of the label is known prior to the expression. Did you re-position the single line of code that I indicated?

Regards,

Mac