SimulIDE 1.0.0 Tester builds.

I think we have here two separate processes:

Yes but both processes write to EECR.

The datasheet is a bit confusing about SBI and CBI:
In several places it states that these instructions can affect bits that are "triggered" in some way by writing a 1 regardless it previous state, for example some interrupt flags.
Some examples:

Some of the Status Flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on all bits in the I/O Register, writing a one back into any flag read as set, thus clearing the flag.

All AVR ports have true Read-Modify-Write functionality when used as general digital I/O ports. This means that the direction of one port pin can be changed without unintentionally changing the direction of any other pin with the SBI and CBI instructions. The same applies when changing drive value (if configured as output) or enabling/disabling of pull-up resistors (if configured as input).

Do not use Read-Modify-Write instructions (SBI and CBI) to set or clear the MPCM bit. The MPCM bit shares the same I/O location as the TXC Flag and this might accidentally be cleared when using SBI or CBI instructions.

Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.

This suggest that if EECR is 0000 0001 and you write 0000 0101 (SBI  EECR, EEMWE) then it can trigger a read operation.

But reading many discussions in the internet seems that this was the case at the beginning but it was "corrected" later and today SBI and CBI never affect other bits, but the datasheets are not updated.

Although I didn't have the idea to check that EERE is reset by hardware soon after reading the byte from EEPROM [during the 4-cycle reading instruction], I think it is the case. But I will check this by running the ATMEL Studio simulator (just to be 100% sure).

Let me know what you find please.

If this issue don't let you test other things you can clear EERE by software after a read, and it should work ok, but eeprom write times for Atmega8 might be wrong.

More on SBI CBI instructions:

I was not aware that these instructions operate differently in different devices, for example:

ATmega8A:

Some of the Status Flags are cleared by writing a logical one to them. Note that the CBI and SBI instructions will operate on all bits in the I/O Register, writing a one back into any flag read as set, thus clearing the flag.

ATmega48A/PA/88A/PA/168A/PA/328/P:

Some of the Status Flags are cleared by writing a logical one to them. Note that, unlike most other AVRs, the
CBI and SBI instructions will only operate on the specified bit, and can therefore be used on registers containing
such Status Flags.

But it is still confusing, in both datasheets states that SBI and CBI are Read-Modify-Write instructions, which implies that it reads the register, changes a bit and writes the whole register back:

Do not use Read-Modify-Write instructions (SBI and CBI) to set or clear the MPCMn bit. The MPCMn bit shares
the same I/O location as the TXCn Flag and this might accidentally be cleared when using SBI or CBI
instructions.

So in ATmega48A/PA/88A/PA/168A/PA/328/P datasheets states that SBI and CBI are Read-Modify-Write instructions in one place and "only operate on the specified bit" in other place.

You are right being confused about CBI and SBI from reading the datasheets.

In my codes, written for ATmega8 (actually ATmega8L or ATmega8A), CBI and SBI affect just one bit (the bit of interest in a byte).

I deal with flags as below:

Code:

;======================
; *** PROGRAM flags ***
;======================
; B_ for SBRC, SBRS
; F_ for SBR, CBR

;.def R1flags  = r25            ; general flags 1, basic
;-------------------------------------------------------

#define B_end2Vi r25,7          ; 1 = end interval for Vi, CYCLnmbr
#define F_end2Vi r25,0x80

#define B_end2Vo r25,6          ; 1 = end interval for Vo, CYCLnmbr
#define F_end2Vo r25,0x40

#define B_on_Off r25,1          ; 1 = over limits for display
#define F_on_Off r25,0x02


For example, if I write,

Code:

  SBR   F_end2Vi
or
  CBR   F_end2Vi


the bit_7 only of r25 is set or cleared while all other flags in r25 are not changed/affected.


About EERE, this flag is supposed to be ‘0’ all the time because when it is set, the hardware clears it during its 4-cycle instruction.

But I will check, in my free time and for knowledge only, what could happen if both, EEMWE and EERE, are set simultaneously by an OUT instruction. In a good code, setting both flags at the same time is avoided. And this also applies for EEMWE and EEWE as in the following note:

Datasheet wrote:5. Write a logical one to the EEMWE bit while writing a zero to EEWE in EECR.
6. Within four clock cycles after setting EEMWE, write a logical one to EEWE.

And besides EERE is always ‘0’ (setting it is much like sending a narrow triggering pulse), it cannot be set while EE is in the writing mode (its setting is ignored).

About the MPCM bit, I am afraid I can’t help, speaking practically, because, in all my applications, I didn’t use the USART protocol for data transfer, just TWI and SPI besides in-house protocols.

About EERE, this flag is supposed to be ‘0’ all the time because when it is set, the hardware clears it during its 4-cycle instruction

Thanks, this will solve this issue regardless of the SBI CBI behavior.

For example, if I write,

Code:
     SBR   F_end2Vi
   or
     CBR   F_end2Vi

the bit_7 only of r25 is set or cleared while all other flags in r25 are not changed/affected.

Yes, there is no problem there, the problem is when there are bits that don't behave in the "standard" way.
For example interrupt flags that are cleared by writing a 1.
MPCM bit is just one example that is mentioned in the datasheet.

If SBI and CBI are Read-Modify-Write instructions this means (at least for me) that it reads the register, changes the bit and writes the WHOLE register again.
It does in just one atomic operation, but it writes the whole register not only that bit:

Note that the CBI and SBI instructions will operate on all bits in the I/O Register, writing a one back into any flag read as set, thus clearing the flag.

Lets say ADCSRA with interrupt flag ADIF  in bit 4, and this bit is already 1, for example: ADCSRA = 1001 0000
Now you do: SBI ADCSRA,0
This instruction will write 1000 1001 to ADCSRA causing the interrupt flag to be cleared because you are writing 1 to bit ADIF.
This is mentioned in ATmega8 datasheet:

Alternatively, ADIF is cleared by writing a logical one to the flag.
Beware that if doing a Read-Modify-Write on ADCSRA, a pending interrupt can be disabled. This also applies if the SBI and CBI instructions are used.

But if SBI and CBI only operates in a single bit this problem does not happen:
ATmega48A/PA/88A/PA/168A/PA/328/P datasheet:

Note that, unlike most other AVRs, the CBI and SBI instructions will only operate on the specified bit, and can therefore be used on registers containing such Status Flags.

But in ATmega48A/PA/88A/PA/168A/PA/328/P datasheet there is also the warning about ADIF which contradicts the statement that SBI CBI only operates in single bits.

So now I don't know if SBI CBI operates in a different way depending on the device or depending on the register or both or what...

In any case if EERE is cleared by hardware then the SBI CBI behavior doesn't matter for this issue.

The flag EEWE in EECR doesn't reset (1 to 0) to indicate end of EE writing (typically, writing a byte takes 8.5 ms).

Flag not reset solved at Rev 1147.
Write time solved at Rev 1148.

arcachofo wrote:Lets say ADCSRA with interrupt flag ADIF  in bit 4, and this bit is already 1, for example: ADCSRA = 1001 0000
Now you do: SBI ADCSRA,0
This instruction will write 1000 1001 to ADCSRA causing the interrupt flag to be cleared because you are writing 1 to bit ADIF.

Good remark. I didn't think of it (or noticed it) because I usually use SBI with (ADCSRA, 4) only and there is no other flag in this register which is cleared with '1'.

But this could be an issue if SBI is used with TIFR, for example, which has many flags that are cleared with '1' in case there is another pending interrupt, if not more than one.
I usually use IN then OUT for TIFR (or the like) after ANDing the temporary register to select the flag to be cleared (by '1', that is by itself). So, I guess, and also for knowledge, I will likely check what could happen if SBI is used with TIFR of ATmega8 when more than one interrupt flag is set.

[It happens I am somehow busy, in these days, in designing the hardware of a new product I am working on. Soon, I will need to write the code of its controller that uses ATmega8 by using ATMEL Studio... and will likely do the check(s) about SBI].

Nice that you are doing all this testing, and specially good that you are doing it in asm.

Atmega8 had very little testing until now, so we have the chance to give it a good push ahead.
And also useful for all AVRs, for example the EEPROM issue applies to all devices.

I'm thinking in some way to save breakpoints, this is important, specially for large files.
Hopefully I get it solved in next days.

I try focusing now on the debugger bugs which are related to code while ignoring, for the time being, the various crashes I may have while debugging.

But I wonder, since we run different operating systems (here, Windows 7 32-bit), how you can repeat a crash on your side, assuming I can repeat it on mine and I give you its details.

But I wonder, since we run different operating systems (here, Windows 7 32-bit), how you can repeat a crash on your side, assuming I can repeat it on mine and I give you its details.

In most cases these issues are related to some error in the code, so it happens in any system.
I also have Win10 in a VM with limited functionality that I can use to get some idea.
And If I can't reproduce the issue at least I know there is a problem related to some functionality and I can just guess what it could be.

I suspect that there is a problem related to the debugger and simulator thread.
And I have a rough idea about what is the cause, hopefully it will be solved soon.

arcachofo wrote:

The flag EEWE in EECR doesn't reset (1 to 0) to indicate end of EE writing (typically, writing a byte takes 8.5 ms).

Flag not reset solved at Rev 1147.
Write time solved at Rev 1148.

For instance, when you solve something in a new version, how could it be available for download?

For instance, when you solve something in a new version, how could it be available for download?

In this post, when I upload new builds.

arcachofo wrote:

For instance, when you solve something in a new version, how could it be available for download?

In this post, when I upload new builds.

I see. Thank you.

New build at Rev 1148 uploaded.

Basically AVR EEPROM fixes.

Have a look at first post for download links.

arcachofo wrote:New build at Rev 1148 uploaded.

Basically AVR EEPROM fixes.

Have a look at first post for download links.

Thank you.

SimulIDE_1.0.0-R1148_Win32

[1]
The EEPROM content is not reset (all bytes to 0xFF) at the start of the debugging session.

ADDED:
And the EEPROM bytes cannot be edited (for example, to reset them manually on the MCU Monitor)

[2]
Resetting (by the 'Reset button) the debugger just returns the cursor position to line 1, then the program freezes (‘Step’ and ‘Run To Breakpoint’ don’t respond). But the debugger could be stopped and run again normally (as long the ‘Reset’ button is not pressed).

For instance, I wonder if it is possible to also watch the bytes in the Static RAM memory [SRAM].

The EEPROM content is not reset (all bytes to 0xFF) at the start of the debugging session.

EEPROM is persistent like in a real device.
You have to re-write via software or manually in Mcu Monitor.

And the EEPROM bytes cannot be edited (for example, to reset them manually on the MCU Monitor)

it is working for me: just click and set the new value:
Decimal: just set the decimal value.
Hexadecimal: use "0x", for example: 0xFF (uppercase or lowercase).

Resetting (by the 'Reset button) the debugger just returns the cursor position to line 1, then the program freezes (‘Step’ and ‘Run To Breakpoint’ don’t respond). But the debugger could be stopped and run again normally (as long the ‘Reset’ button is not pressed).

I will have a look...

For instance, I wonder if it is possible to also watch the bytes in the Static RAM memory [SRAM].

SRAM is in the RAM tab.
You can see part of it at the right side, just expand the Mcu Monitor window to the right and readjust the splitter.
Note that the splitter has 3 panels:
- List of Registers at the left.
- Watch Registers/Variables in the middle.
- RAM table at the right.
You can expand/collapse them as you want.

arcachofo wrote:

The EEPROM content is not reset (all bytes to 0xFF) at the start of the debugging session.

EEPROM is persistent like in a real device.
You have to re-write via software or manually in Mcu Monitor.

Yes, the content of EEPROM, unlike the RAM and SRAM memories, is supposed to be persistent on a real controller board. But this is important 'only' when the MCU runs its code that was finished and examined that it has no bugs, including the ones related to EEPROM functions.

I am afraid that a real debugger resets the MCU EEPROM as if the MCU is a fresh one (erased fully) in case there is, for example no *.eep file that defines the initial values of some (or all) bytes in EEPROM. In other words, the debugger assumes that the code runs, for the first time, in a fresh programmed MCU.

If restarting/resetting the debugger doesn't return the initial values of EEPROM bytes (all as 0xFF or as defined by a separate file), testing the newly written functions related to EEPROM cannot be done properly.
Fortunately, the simulator of ATMEL Studio resets the MCU EEPROM.

arcachofo wrote:

And the EEPROM bytes cannot be edited (for example, to reset them manually on the MCU Monitor)

it is working for me: just click and set the new value:
Decimal: just set the decimal value.
Hexadecimal: use "0x", for example: 0xFF (uppercase or lowercase).

I see. MCU Monitor accepts both types while editing bytes.
The programs, I am familiar to, accept hexadecimal only (so no need of 0x in their case).

For instance, the watch list of the MCU Monitor shows values in decimal and binary.
Is it hard to add a column for hexadecimal?

arcachofo wrote:

For instance, I wonder if it is possible to also watch the bytes in the Static RAM memory [SRAM].

SRAM is in the RAM tab.
You can see part of it at the right side, just expand the Mcu Monitor window to the right and readjust the splitter.
Note that the splitter has 3 panels:
- List of Registers at the left.
- Watch Registers/Variables in the middle.
- RAM table at the right.
You can expand/collapse them as you want.

Thanks, I see the table now.

In my test code (test_01_v2.asm attached), the ‘ADC prescaler select bits’ (ADPS2:0 in ADCSRA) are set for the division factor of 64.
In the ADC free running, reading a sample takes 13 cycles (the first reading only takes 25 cycles).
The sampling time is, in this case, 64*13=832 cycles.
If we set a breakpoint at the instruction IJMP (line 604), the debugger shows, at the next pass, 928 cycles instead of 832.


On the other hand, I wonder if it is possible to append the time (I guess ‘in us’ is enough practically) after the ‘Clock Cycles’.

But the ideal line of the debugger 'Clock Cycles' could be:
Clock Cycles: x1 , us: x2 , Total Cycles: x3 , Total us: x4

Where
x1 = the number of cycles between two breakpoints or a single step.
x2 = x1 * 1/F (in us)
x3 =  x1 + previous x3
x4 = x3 * 1/F (in us)

But for this extra data to be useful (practical), there is a need for an extra button (and/or a hotkey) to reset x3 to 0 when necessary, during debugging.

I am afraid that a real debugger resets the MCU EEPROM as if the MCU is a fresh one (erased fully) in case there is, for example no *.eep file that defines the initial values of some (or all) bytes in EEPROM. In other words, the debugger assumes that the code runs, for the first time, in a fresh programmed MCU.

Most debuggers don't work with a "circuit", so they rely on an .eep file.
SimulIDE is similar to an in-circuit debugger, but the circuit is virtual.

If restarting/resetting the debugger doesn't return the initial values of EEPROM bytes (all as 0xFF or as defined by a separate file), testing the newly written functions related to EEPROM cannot be done properly.
Fortunately, the simulator of ATMEL Studio resets the MCU EEPROM.

That depends on the program, some programs might need to read previous EEPROM values and resetting it don't  allow you to debug it properly.

Anyway there are many possible use cases.
Maybe the best solution is to add an option to make EEPROM persistent or not.

For instance, the watch list of the MCU Monitor shows values in decimal and binary.
Is it hard to add a column for hexadecimal?

Yes that is in the plan.

In the ADC free running, reading a sample takes 13 cycles (the first reading only takes 25 cycles).
The sampling time is, in this case, 64*13=832 cycles.
If we set a breakpoint at the instruction IJMP (line 604), the debugger shows, at the next pass, 928 cycles instead of 832.

I will have a look.

But the ideal line of the debugger 'Clock Cycles' could be:
Clock Cycles: x1 , us: x2 , Total Cycles: x3 , Total us: x4

Where
x1 = the number of cycles between two breakpoints or a single step.
x2 = x1 * 1/F (in us)
x3 =  x1 + previous x3
x4 = x3 * 1/F (in us)

But for this extra data to be useful (practical), there is a need for an extra button (and/or a hotkey) to reset x3 to 0 when necessary, during debugging.

Yes, that would be useful.

arcachofo wrote:Maybe the best solution is to add an option to make EEPROM persistent or not.

You are right. There are many cases. So, by adding this option, all cases will be covered.

May I add.

If this project were mine, I focus first on making its debugging process as easy as possible for the user. This encourages almost every tester, including me, to repeat a code test (with the same SimulIDE revision or an updated one) even if he has a relatively short free time.

In my view, I would focus now on:
[1]
Saving the look of the MCU Monitor with its circuit.
For example, the RAM/SRAM table could be seen, therefore, as it was set (displayed) in the previous session.

[2]
Changing, on the MCU Monitor and in a convenient way, the displayed values DEC to HEX or HEX to DEC (instead of adding another column). This option eases, when necessary, the comparison between a hex value of a byte on the RAM table (mid panel) with one on the SRAM table (right panel).

[3]
Saving the defined breakpoints on a code (under test) just before exit so that they can be restored with their code later. Their maximum number may need to be limited, as convenient to the usage memory of SimulIDE.

[4]
Activating/deactivating the search function during debugging though it keeps working if activated in the edit mode before starting the debugger.
The ideal ‘search’ has a history list for the last entries. Their number also needs to be limited as convenient.

I think monitoring the SRAM bytes (defined as single bytes only, not of an array) also by their defined names is not easy to implement, at least for the time being.

Note:
I am sorry for not being able joining the developers. Due to the world's regulations, since many decades ago, I am not allowed downloading/using any C compiler on Windows, free or paid (and I don’t like using hacked programs). Therefore, the last one that I was able to buy was of the BorlandC 3.1 package (so when real necessary, I write a C program on DOS for a specific task that usually relates to what I design or work on).

@KerimF
Those are all good points, but you you need to consider several things:

a- Debugger depends on several parts of the program.
They all need to be developed together.

b- The program is still changing.
Implementing too many details can be lost time because a new configuration changes everything.
Future plans need to be considered before adding code (related to a-).

And once you implement a new feature it can be difficult or not possible to change (keep backwards compatibility).

c- Microcontrollers is only a part of the program, debugging is a part of that part and the program is a part of the whole project.
There are many other things to do.

d- Resources are limited.
By now only me for several things: code, deploy, website, forum, tutorials, videos, graphic design, one translation...
Fortunately now we have a few good testers, if not we would be years behind.
So I need to focus first in the most critical: making the thing to work, then improving a bit more and so on.

About your points:
[1][2] This depends on the Mcu Monitor re-design (related to b-).
Good points, but the whole Mcu Monitor need to be defined first.

[3] This is in the immediate plans, but first I need to solve other critical issues (related to d-).

[4] Searching during debugging is already done.
Ideal search: good idea, but much lower priority than [1][2][3] and a few other things.


I added your points to the relevant discussion so they don't get lost in this discussion:
https://simulide.forumotion.com/t946-redesigning-mcu-monitor

Note:
I am sorry for not being able joining the developers. Due to the world's regulations, since many decades ago, I am not allowed downloading/using any C compiler on Windows, free or paid (and I don’t like using hacked programs). Therefore, the last one that I was able to buy was of the BorlandC 3.1 package (so when real necessary, I write a C program on DOS for a specific task that usually relates to what I design or work on).

Politics always helping the people.. I love them

Thank you for your detailed reply.
So, let us live with what we have.

About 1.0.0-R1148, I try not to press 'Reset' while debugging the test code (for ATmega8). If I do, I have to 'stop' the debugger (the only button alive) and restart it.