An overview of some issues related to AVRstudio 6.2 and its simulatior

Go To Last Post
5 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

For about 20 years, I used writing my codes (in assembly) for Atmel C51 family (starting from AT89C2051).

The only tools, I had, were the assembler TASM (via its DOS command line) and a general programmer (renewed when possible).

Lately, I got ATmega8 MCUs. And thanks to AVRstudio 6.2 (offered by Atmel), I was able writing my first test codes (also in assembly) to become familiar with the megaAVR family.

Also thanks to this forum, I already learnt a lot by searching its posts before joining it.

I would like knowing if any of the following known issues (five, below) of the compiler/simulator (integrated in AVRstudio 6.2) are fixed or not yet.

Please note, I expect very short replies on this overview thread. Then, if necessary, further discussing of any point will be on a separate thread (having a title that could help for future searching).

Naturally, in case an issue is not fixed yet, I will, as most of you did, try finding a suitable workaround to fix it (temporarily in the least).

===
(1)
The data of the flash and EEPROM are generated on two separate files (on *.hex and *.eep respectively).

Since I use a conventional parallel programmer, I wished there is an option that lets both data be included on one file.

 

(2)
After searching in this forum, I noticed that, in general, the fuses and lock bits (of ATmega8) should be set ‘manually’ via the programmer’s configuration menu (related to the ATmega8 for example).

 

(3)
Even if the EEPROM space is not used, the simulator reads its first byte (at address 0x00) as 0x00 instead of 0xFF which is the physical value for a non-programmed byte.

 

(4)
About saving SREG outside the interrupt routines, the following instruction
    IN    sregTemp, SREG
saves the flags b6..0 of the Status Register (SREG) in sregTemp.
But it also clears b7 before saving it in ‘sregTemp’, as if it is at the start of an interrupt routine.

 

(5)
It is about reading PINx as explained below:

 

Case 1:
Port B is initialized by the following two instructions:
    OUTI  PORTB, 0b11110000     ; PPPPLLLL
    OUTI  DDRB , 0b00001111     ; iiiioooo
PINB will be read later by the simulator as 0b00000000 (zero for all 8 bits).  

 

Case 2:
Port B is initialized by starting with an additional DDRx instruction that sets all pins as input:
    OUTI  DDRB , 0b11111111     ; iiiiiiii, all as input
    OUTI  PORTB, 0b11110000     ; PPPPTTTT, for PPPPLLLL later
    OUTI  DDRB , 0b00001111     ; iiiioooo
PINB will be read later by the simulator as 0b11110000 as expected.
===

 

Thank you.

 

Kerim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(1) You can generate and program "ELF production files" that contain, in a single file, all of code, eeprom, fuse and lock data. I think the most recent builds of avrdude can (like Studio 6.2 used with Atmel programmers) use such files.

 

(2) no, not necessarily - as I say you can embed fuse/lock in the ELF and just have everything programmed in one go. Apart from industrial production though, I don't see the point. Fuses are something you normally only set once the first time you take a chip from the tube/packet and after that you are unlikely to touch them. So I'd just do that once, manually. After that just program flash and eeprom as required.

 

(3) never heard of such a simulation fault but even if it did once exist I don't think it does in 6.2SP1. It does kind of raise the question of why you'd be reading somewhere you expect there to be no data but I suppose you might be looking for a "cookie" value to determine if the defaults had already been programmed (if so I'd suggest 0x00 and 0xFF are NOT good cookie values - something like 0x5A would be far better).

 

(4) that's an old bug that's been fixed

 

(5) the AVR does not have an "OUTI" instruction - perhaps you mean just "OUT" but that is from a register so you need to LDI R(16..31), n then OUT addr, Rn

 

Anyway if your general point in (5) is that PIN read back "lags" setting PORT by 1 cycle this is right and reflects correct AVR behaviour.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you, clawson, for your prompt and detailed reply.

 

(1) Since I have a third-party programmer, I think I should write a small 'exe' to add the EEPROM data (in eep file) to the flash data (in hex file) when I will need using it in the source.

 

(2) For the time being, I need changing the fuses more often since I work on different testing projects. Fortunately, I noticed that my programmer adds a line to the flash data when its reads an ATmega8 MCU.
For example, this line looks as the following one:

 

:10220000E4ABF9FF0003FFFFFFFFFFFFFFFFFFFF4E

 

As we see, its address is at 0x2200.
The first byte (as 0xE4 here) happens to be the low-byte of the fuses.
The third byte (0xF9) is for their high-one.
The forth byte is for the lock byte (0xFF here).
The 2nd byte (as AB here) is the calibration byte (set by ATMEL, hence never used by the programmer other than reading it). And it is for the internal RC frequency which is referred by the 5th and 6th bytes (as 0x0003 here of the internal 8 MHz; 0x0002 to 0x0000 are for 4, 2 and 1 MHz respectively).
So I wrote a small exe (running on DOS) that could be called automatically by each project (post-build) with 3 bytes as parameters for the suitable fuses and lock bits of the project.

 

(3) A few weeks ago, I downloaded 6.2 (is it 6.2SP1?).
You are right about raising the question. In my program, a default setting (2 bytes) is in the flash. It could be changed and stored on EEPROM later when necessary. It happened I chose the first 2 bytes of the EE space. So I checked the first byte (at 0x00, supposed to be the high byte of the user setting that cannot reach 0xFF) if it is programmed or not. I was surprised that, no matter what I did, the simulator reads it (unlike all other 511 bytes) as zero always. Of course, I could change the address but I decided to swap the high and low bytes and check, after reset, the second byte (at 0x01)... to please the simulator.

 

(4) First, I had the following code (as suggested on the datasheet):

 

  in sregTemp, SREG ; store SREG value
  cli ; disable interrupts during timed sequence
  sbi EECR, EEMWE ; start EEPROM write
  sbi EECR, EEWE
  out SREG, sregTemp ; restore SREG value (I-bit)

 

But anytime it is executed, the global interrupt is cleared aftwards.
At the code output, I checked the bits of ‘sregTemp’. Its b7 was always 0.  
I fixed it with a simpler code as:

 

  cli ; disable interrupts during timed sequence
  sbi EECR, EEMWE ; start EEPROM write
  sbi EECR, EEWE
  sei ; re-enable interrupts

 

(5) You are right. OUTI is one of my macros that uses both LDI and OUT (using a register reserved always for such macros).

I'm afraid that, in the second case only, the I/O watch window gave the expected reading of PINB during the simulation session. In the first case, its bits were shown (also on this window) always as cleared even if the outputs in PORTB were changed (set or cleared by software).

 

Last Edited: Mon. Jan 26, 2015 - 03:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(1) Since I have a third-party programmer, I think I should write a small 'exe' to add the EEPROM data (in eep file) to the flash data (in hex file) when I will need using it in the source.

How could that possibly work? the whole issue is that Intel Hex (and Srecord and all the others) are inherently von Neumann while an AVR is Harvard. You need some way to differentiate address spaces in a linear address map. Microchip have done this in the past so a .hex for their chips can hold both code and fuses with one offset to a "high" address but this requires all programming software dealing with such hex files to know about this. In fact the way the avr-gcc compiler and linker handle Harvard using a vo Neumann linker is something very similar. They offset EEPROM to a 0x800000 base but this only works because all the tools dealing with such (ELF) files know about the offsetting - standard ELF processing tools would be most puzzled.

 

As I said ELF is a "container format" - it can hold several memory spaces in a single file. Atmel and the AVR-LibC team have used this to be able to put code, errpom, fuse and lock data into the one file and the avrdude maintainer (also an AVR-LibC maintainer) has done the work to make avrdude aware of this too - so your best bet here is to use AS6.2 to create "ELF production files" nd then use a recent avrdude to drive your porgrammer - a version that knows about .fuse and so on in the ELF.

 

Or just do what all AVR programmers have been doing for near 15 years and create TWO intel hex files. One or the code and one for the EEPROM. It is usual to give the EEPROM a .eep extension even though it really is just .hex

 

(2) boy oh boy you are really over-thinking and over-engineering something that is actually really simple!?!

 

(3) then you aren't using it right. Watch out for Studio 6's caching - though I sort of assumed it would be turned off by default for EEPROM (which is subject to run time change). Certainly for flash it is very recalcitrant about spotting changes which makes SPM code "fun" but, as I say, it has a way to switch off the caching.

(4) But anytime it is executed, the global interrupt is cleared aftwards.

Sorry - you are saying this happened in AS6.2SP1? I was sure the SREG I-bit thing was fixed.

 

(5) You know what the fix is for simulation faults? Don't waste time with a simulator! They are just code and if can be subject to bugs so you could waste large chunks of your life hunting others bugs. Why not get an OCD interface and run the code in a real AVR - they don't lie (though I suppose there's an outside possibility that the debugger might have a bug too?).

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you again, clawson.

 

First, may I say that I agree with you on all what you liked telling me... if...

I don't know how to express my situation. I mean, what could be available (free or paid) to many people on earth may not be so to those who were born and live in some countries.

 

So, I liked it or not, I had to be over-thinking (think out of the box) and over-engineering anytime I have a technical problem to solve in my designs (I run a small private business in electronics after graduation, for about 40 years so far).

 

Even now, I have no choice but writing, when necessary, my small C programs (exe for DOS) using the BorldandC package that I bought about 3 decades ago. And, as I mentioned it earlier, I had to also use a DOS assembler (as TASM) with a text editor for programming Atmel C51 MCUs during the last 20 years (I started with Z80 in early years). So having now the AVRstudio 6.2 (for the ATmega8 MCUs I got lately) is, in itself, a great gift to me (from ATMEL), despite any bugs it may have now.

 

Best wishes,

Kerim