The Debugger May Lost its Cursor

SimulIDE_1.0.1-R1386_Win32

I wrote an AVR assembly code (ATmega8) for the acid battery charger. It is somehow complex because it considers many cases.

After fixing many bugs, I got finally: SUCCESS!!! Compilation Ok.

So I prepared myself to find and fix many more serious bugs by running the debugger.

I started the debugger.
When it became ready, I pressed ‘Step’.
But the simulation run continuously as if I pressed ‘Run to Breakpoint’.
So, I pressed ‘Pause’ to see at which instruction the debugger cursor is.
The simulation stopped and the cursor was on the first line!
So, I set a breakpoint at an initial instruction then I pressed ‘Reset’ followed by ‘Run to Breakpoint’.
Again, there was no halt. And by pressing ‘Pause’, the cursor didn’t move from the 1st line.

In brief, no matter what I did, the debugger couldn’t let its cursor move from the first line, and, therefore, it couldn’t detect any breakpoint.

In case this shouldn’t happen no matter sim1 and asm files might be, I will attach the rather big files shown below (after being zipped).

The related files to this situation are:

XF_3-2_09a.asm [99K] , XF_3-2_09a.sim1 [44K] , XF_3-2_09a.hex [11K]
Zipped [33K]

And

XF_3-2_09a.lst [203K],
Zipped [40K]

There are many things that can happen:

- Does it generate a valid firmware? (have a look at the lst file)
- Are there any source lines mapped? (look at the messages at bottom panel)
- Is the PC increasing while debugging? (have a look at Mcu Monitor)

The related files to this situation are:

I don't have those files.
Maybe some error while attaching?

arcachofo wrote:There are many things that can happen:

- Does it generate a valid firmware? (have a look at the lst file)
- Are there any source lines mapped? (look at the messages at bottom  panel)
- Is the PC increasing while debugging? (have a look at Mcu Monitor)

The related files to this situation are:

I don't have those files.
Maybe some error while attaching?

I didn't attach them before hearing your comment because their sizes are relatively big.

Please note, I will send them as they are.
The comments in the code may be wrong, if not silly sometimes, because I didn't revise them to save time.
Also, the circuit is not finished. So it doesn't matter if it won't run right.

But I hope they will help to know what makes the debugger loses its control over its cursor.

Seems like the Microcontroller is in reset state.
It is configured to use the reset pin but there is no reset circuit.

arcachofo wrote:Seems like the Microcontroller is in reset state.
It is configured to use the reset pin but there is no reset circuit.

Many thanks, I knew I missed something as usual
Sorry, for taking your time.

arcachofo wrote:Seems like the Microcontroller is in reset state.
It is configured to use the reset pin but there is no reset circuit.

It seems, on your side, after you deselected pinC6 (to let it be an open I/O pin) or you just connected pinC6 to 5V (to reset MCU), the debugger cursor moved normally.

On my side, these two changes couldn’t solve the issue. In other words, there is no connection between the circuit and the active debugger other than ‘powering the circuit’ and ‘pausing the simulation’.

I just assumed that it was the only problem.
I didn't realize that Frequency = 0 MHz.

arcachofo wrote:I just assumed that it was the only problem.
I didn't realize that Frequency = 0 MHz.

My bad, I used programming the MCUs with a parallel programmer (not a serial one). So I wrote a small DOS exe to append automatically (when called by a batch file, see 2nd line in XF_3-2_09.asm) the settings of the fuses at the end of the hex file, right after 'AVR Studio' creates it (post task).

I have to remember now that the hex file, generated by SimulIDE, is a conventional one which is not supposed to include the fuses and locks bits.

Thank you again for being patient and continuous care.

I found that the issue with frequency = 0 is an error.
It should set a default value, usually 16 MHz for AVRs, but this was broken after a recent change.

Solved at trunk Rev 1430.

arcachofo wrote:I found that the issue with frequency = 0 is an error.
It should set a default value, usually 16 MHz for AVRs, but this was broken after a recent change.

Solved at trunk Rev 1430.

Although I usually run my ATmega8 MCUs at 8 MHz (the upper limit of their internal oscillator), the 16 MHz default is much better than 0.

Although I usually run my ATmega8 MCUs at 8 MHz (the upper limit of their internal oscillator), the 16 MHz default is much better than 0.

The problem happened after implementing default frequencies for each model.
Previously all MCUs defaulted to 16 MHz.
Now there are defaults for AVR=16 and PIC=20, but it is possible to set a default value for individual models.