About Working with AVRASM2 assembler

Typically, the following loop takes about 8.5 ms (programming time on the internal EEPROM):

Code:

EE_wait:

SBIC EECR, EEWE ; wait to end saving
RJMP EE_wait

EEiniRt:
RET


But, it seems that the flag EEWE doesn’t reset (from 1 to 0). Therefore, the debugger cannot exit the loop.

Edited:
The MCU is ATmega8.

But, it seems that the flag EEWE doesn’t reset (from 1 to 0). Therefore, the debugger cannot exit the loop.

Seems that there is an error in one xml file, you can solve it this way (not tested):

Edit file data/AVR/mega8/mega8_regs.xml line 74:

Change from this:
bits="EERE,EEWE,EEMWE,EERIE,0,0,0,0"
To this:
bits="EERE,EEWE|EEPE,EEMWE|EEMPE,EERIE,0,0,0,0"

I think, before going on, I better wrote a simple code for test.

I said this, because the debugger cursor is stuck at the first line; no matter if it is a comment or a blank line, and no matter if the 'Step', 'Run to Breakpoint' or 'Pause' icon is pressed.

Note: This started to happen even before making the change (you suggested). So, I wonder how the cursor went, once!, to the loop after pressing the 'Pause' icon.

I attached an example, ‘test_01_ATmega8’, of an ASM code written for avrasm2 with its test circuit and avrasm2.xml.

I hope it helps.

Note:
The attached asm file, test_01.asm, is recognized by SimulIDE as 'Avr asm' though it was extracted from the previous one REG_5BD_10.asm (seen as unknown).
I will try to find out the cause by adjusting the latter in steps, till it will be recognized. I will post a note about it when it will be found.

What about the fuse low and high bytes?

I usually program an MCU by using a parallel programmer.
So I wrote a small PC program (on DOS) to append automatically the necessary fuses of an application (also its lock bits) at the end of the hex file, generated by Atmel Studio. And, by using a bat file, the resulted hex file is also moved automatically into the parallel programmer folder (ready for programming the MCU).

For example, the appended 2 lines for test_01.asm (and REG_5BD_10.asm) are:
:1022000024AB79ff0003FFFFFFFFFFFFFFFFFFFF8E
:10221000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFCE

The fuse low byte = 0x24
The fuse high byte= 0x79

This means:
internal RC , 8.0 MHz
6 ck + 65 ms, slowly rising power
Brown-out Detection enabled
BOD(bot)=4V
Reset at 0x0000
Bootsize 1024 words 32 pages
Chip Erase erases EEPROM
disable Serial Downloading
WDT turns on by Software only
PC6 for I/O pin

The lock fuses      = 0xFF (no lock)

By the way, after running ‘SimulIDE_1.0.0-RC3_Win32’, the tabs ‘Properties’ and ‘RamTable’ on the left panel are not shown; even by running ‘SimulIDE_0.4.15-SR10_Win32’.

I wonder if this topic could be moved to the 'Microcontrollers' forum.
Sorry for not being attentive in doing it in the first place.

KerimF wrote:
The attached asm file, test_01.asm, is recognized by SimulIDE as 'Avr asm' though it was extracted from the previous one REG_5BD_10.asm (seen as unknown).
I will try to find out the cause by adjusting the latter in steps, till it will be recognized. I will post a note about it when it will be found.

I trimmed most non-code lines of the original 'REG_5BD_10.asm' file but it is still not recognized (unlike 'test_01.asm').
Obviously, I can't trim or change any of its code lines which are simulated properly by 'ATMEL Studio' (and its firmware works on a real board).

So I wonder what could be the criteria, followed by SimulIDE, to detect the type of the source (in this case, an asm file).

Thank you.

I trimmed most non-code lines of the original 'REG_5BD_10.asm' file but it is still not recognized (unlike 'test_01.asm').

To find why REG_5BD_10.asm is not recognized I should have that file.

I'm doing some improvements, but anyway it will be cases that can't be recognized.
In development version you can set the syntax file in compiler xml file, but this was not included in 1.0.0.
I will add it to 1.0.0 and upload new version soon.

I hope you will have time to run the debugger for 'test_01.asm' (in attached zip above).

Although the file is recognized but the cursor of the debugger doesn't move; no matter what I do.

On the circuit panel (central panel), I noticed that the program started (a few 50 Hz cycles could be seen on the scope). But it is halted somewhere and the 'frozen' cursor (on the right panel) can't point to it.

I hope you will have time to run the debugger for 'test_01.asm' (in attached zip above).

I will try to install the bloated Microchip tools...
There is not Linux version for AVR tools, so I can't test avrasm2.

Although the file is recognized but the cursor of the debugger doesn't move; no matter what I do.

We still don't know if your avrasm2.xml file is correct.

I see one problem:
type="avrasm2" is not correct, it must be type="avrasm01" or type="avrasm00" depending on the format of the .lst file.
It could also happens that the .lst format used by avrasm2 is not supported.
You can try both and see which one works or share a .lst file and I will tell you which one to use.

Check the output at bottom panel, you will see something like this:

Code:

Mapping Flash to Source... 42 lines mapped

Debugger Started

The number of mapped lines should be similar to the number of lines containing actual asm instructions (not declarations, definitions, etc).


To properly setup a new compiler/debugger you should start with something simple like a blinking led.
Once you know that the compiler and debugger is working properly, then try to compile and debug a more complex program.

I will follow your suggestions. Thank you.

arcachofo wrote:
You can try both and see which one works or share a .lst file and I will tell you which one to use.

Please see the attached 'test_01_ATmega8_2.zip', which includes also *.lst and *.hex.

I think the correct type in avrasm2.xml is: type="avrasm00".

arcachofo wrote:I think the correct type in avrasm2.xml is: type="avrasm00".

Thank you.
The debugger cursor moved (but after a few steps the program crashed).
Unfortunately, I couldn't repeat that crash.
After the cursor moved as expected, the debugger couldn't detect the flag GIFR, INTF1
in

Code:

INIwait:
; dimming LED loop if no mains
    INC   loopHi
    CBI   Mid_Out
    CPI   loopHi, 25
    BRSH  INIwtC1

    SBI   Mid_Out

INIwtC1:
    IN    tmpHiU, GIFR
    SBRS  tmpHiU, INTF1  ; <=====
    RJMP  INIwait

;===
; reset mains interrupt
    OUT   GIFR, tmpHiU


On the MCU monitor, the INT1 bit [b3] of the I/O register PIND flips [0V-5V-0V...] as driven by the square wave generator [50Hz, 50%].

the debugger couldn't detect the flag GIFR, INTF1

There is a typo in an xml file.
Edit file data/AVR/mega8/mega8_regs.xml line 143:
From this;
bits="0,0,0,0,0,0INTF0,INTF1" />
To this (missing comma):
bits="0,0,0,0,0,0,INTF0,INTF1" />

arcachofo wrote:

the debugger couldn't detect the flag GIFR, INTF1

There is a typo in an xml file.
Edit file data/AVR/mega8/mega8_regs.xml line 143:
From this;
bits="0,0,0,0,0,0INTF0,INTF1" />
To this (missing comma):
bits="0,0,0,0,0,0,INTF0,INTF1" />

Now, resetting the flags in GIFR (cleared by a logical 1) doesn't work. This is usually done by copying GIFR into itself.

Code:

1655 INIwtC1:
1656 IN tmpHiU, GIFR
1657 SBRS tmpHiU, INTF1
1658 RJMP INIwait
1659
1660 ;===
1661 ; reset mains interrupt
1662 OUT GIFR, tmpHiU   ; <===== has no effect


Now, resetting the flags in GIFR (cleared by a logical 1) doesn't work.

This should be fixed by:
Edit file data/AVR/mega8/mega8_int.xml lines 5 and 6:
From this:

Code:

<interrupt name="INT0" enable="INT0" flag="INTF0" priority="18" vector="0x001"/>
<interrupt name="INT1" enable="INT1" flag="INTF1" priority="17" vector="0x002"/>

To this (add clear="1"):

Code:

<interrupt name="INT0" enable="INT0" flag="INTF0" priority="18" vector="0x001" clear="1"/>
<interrupt name="INT1" enable="INT1" flag="INTF1" priority="17" vector="0x002" clear="1"/>

I added

Code:

clear="1"

but, unfortunately, this didn't clear the flag INTF1 in GIFR [I also checked the register GIFR on the MCU monitor].

Code:

<parts>
    <interrupts enable="I">
        <interrupt name="RESET"                                priority="19" vector="0x000"/>
        <interrupt name="INT0"    enable="INT0"   flag="INTF0" priority="18" vector="0x001" clear="1"/>
        <interrupt name="INT1"    enable="INT1"   flag="INTF1" priority="17" vector="0x002" clear="1"/>
        <interrupt name="T2CO"    enable="OCIE2"  flag="OCF2"  priority="16" vector="0x003" clear="1"/>
        <interrupt name="T2_OVF"  enable="TOIE2"  flag="TOV2"  priority="15" vector="0x004" clear="1"/>
        <interrupt name="T1CAP"   enable="TICIE1" flag="ICF1"  priority="14" vector="0x005"/>
        <interrupt name="T1COA"   enable="OCIE1A" flag="OCF1A" priority="13" vector="0x006" clear="1"/>
        <interrupt name="T1COB"   enable="OCIE1B" flag="OCF1B" priority="12" vector="0x007" clear="1"/>
        <interrupt name="T1_OVF"  enable="TOIE1"  flag="TOV1"  priority="11" vector="0x008" clear="1"/>
        <interrupt name="T0_OVF"  enable="TOIE0"  flag="TOV0"  priority="10" vector="0x009" clear="1"/>
        <interrupt name="SPI"     enable="SPIE"   flag="SPIF"  priority="9"  vector="0x00A"/>
        <interrupt name="USART_R" enable="RXCIE"  flag="RXC"   priority="8"  vector="0x00B" clear="0"/>
        <interrupt name="USART_U" enable="UDRIE"  flag="UDRE"  priority="7"  vector="0x00C" clear="0"/>
        <interrupt name="USART_T" enable="TXCIE"  flag="TXC"   priority="6"  vector="0x00D" clear="1"/>
        <interrupt name="ADC"     enable="ADIE"   flag="ADIF"  priority="5"  vector="0x00E"/>
        <interrupt name="EEPR"    enable="EERIE"  flag=""      priority="4"  vector="0x00F"/>
        <interrupt name="ACOMP"   enable="ACIE"   flag="ACI"   priority="3"  vector="0x010"/>
        <interrupt name="TWI"     enable="TWIE"   flag="TWINT" priority="2"  vector="0x011" clear="0"/>
        <interrupt name="SPM"     enable=" "      flag=" "     priority="1"  vector="0x012"/>
    </interrupts>
</parts>

but, unfortunately, this didn't clear the flag INTF1 in GIFR [I also checked the register GIFR on the MCU monitor].

Yes, looks like there is an error in the code.
Solved at Rev 1353.

arcachofo wrote:

but, unfortunately, this didn't clear the flag INTF1 in GIFR [I also checked the register GIFR on the MCU monitor].

Yes, looks like there is an error in the code.
Solved at Rev 1353.

Thank you,
So, I will wait till this revision could be downloaded.

Edited:
I run Windows 7 32-bit

Simulide Rev 1148 does not work with Avrasm2 for me.  
 Tool Path:  C:/Program Files(x86)/Atmel/Studio/7.0/toolchain/avr8/avrassembler/
 Include Path: C:/Program Files(x86)/Atmel/Studio/7.0/packs/atmel/ATmega_DFP/1.7.373/avrasm/inc/
Error message is:  Executable not found

Avra does work.
Avrasm2 does work with Microchip Studio and with MPLab X IDE.

https://servimg.com/view/20479992/3
[url=https://servimg.com/view/20479992/9]
failure of Avrasm2


Success of Avra


working settings in MPLab X IDE


working settings in MicroChip Studio

AS4 also builds a hex file that works in SimulIDE.

What does work is this combination



Put all three files together, a copy of the avrasm2.exe application, the source .asm file and the  definition file.

Tool Path:  Atmel/Studio/7.0/toolchain/avr8/avrassembler/
Include: ../Studio/7.0/packs/atmel/ATmega_DFP/1.7.373/avrasm/inc/

One possible problem is that these are not full paths.

You usually select path by clicking in the button at the right side and going to the folder (or entering a full path):