#9 AVR8 support

[Brutte]

Based on this suggestion:

I have added and ~tested an ATMega16 xml file with JTAGICEMk1.
It is far from "complete" but quite usable. I will try to add more peripherals or perhaps even more chips later. Currently it supports GPIOs, ADC, TWI, part of TCNTs etc. It is enough to unzip into /data folder of EmbSys.

Some remarks:

• Naming conventions are taken from Atmel's datasheets, but some descriptions were slightly modified. For example instead of PORTA->PORTA there is GPIOA->PORTA (STM32-ish).
• I do not know how to handle access to some hardware-buffered registers (ADC, OCRnx in PWM mode, UDRn, etc). For these "difficult" registers their names were appended with "!JTAG cannot %s!" strings for now. Accessing (r/w) those locations can possibly influence peripheral operation (dongle manual explains that). Thus my next suggestion for "access" tag which would allow only listing a register (neither r nor w, without rights for access).
• I do not know how to access PC. On AVR8 PC is not mapped into memory space (it does not have the address). This register is accessed from regular "Registers" view in Eclipse so that is a minor problem, but it would be nice to have it somewhere near SREG and SP too.
• If the reset value of a register is known, its value is given in an xml file (like for example DDRA is 0x00 at reset). If it is not, then it is not given (like PINA which has undefined value at reset). Unfortunately current EmbSys fills implicit 0x0 value when explicit value is not given. It would be great to have a resetvalue together with resetmask tag.
• Some bitfields are cleared by writing 0b0, some by writing 0b1. I do not know how to maintain that.

EDIT: New version of ATMega16 1v26 with EEPROM and Flash

[Brutte]

• Description has changed:

Diff:

--- old
+++ new
@@ -7,8 +7,8 @@
 Some remarks:

 * Naming conventions are taken from Atmel's datasheets, but some descriptions were slightly modified. For example instead of PORTA->PORTA there is GPIOA->PORTA (STM32-ish).
-- I do not know how to handle access to some hardware-buffered registers (ADC, OCRnx, UDRn, etc), it seems these are not easily accessible. For these "difficult" registers their  names were appended with "!JTAG cannot %s!" strings for now. Accessing those locations can possibly influence peripheral operation (dongle manual explains that). Thus my next suggestion for "access" tag which would allow only listing a register (neither r nor w).
-- I do not know how to access PC. On AVR8 it is not mapped into memory space(it does not have the address). This register is accessed from regular "Registers" view in Eclipse so that is a minor problem, but it would be nice to have it somewhere near SREG and SP.
-- If the reset value of a register is known, it's value is given in an xml file (like for example DDRA is 0x00 at reset). If it is not, then it is not given (like PINA which has undefined value at reset). Unfortunately current EmbSys fills implicit 0x0 value when explicit value is not given..
+- I do not know how to handle access to some hardware-buffered registers (ADC, OCRnx in PWM mode, UDRn, etc). For these "difficult" registers their  names were appended with "!JTAG cannot %s!" strings for now. Accessing (r/w) those locations can possibly influence peripheral operation (dongle manual explains that). Thus my next suggestion for "access" tag which would allow only listing a register (neither r nor w, without rights for access).
+- I do not know how to access PC. On AVR8 PC is not mapped into memory space (it does not have the address). This register is accessed from regular "Registers" view in Eclipse so that is a minor problem, but it would be nice to have it somewhere near SREG and SP too.
+- If the reset value of a register is known, its value is given in an xml file (like for example DDRA is 0x00 at reset). If it is not, then it is not given (like PINA which has undefined value at reset). Unfortunately current EmbSys fills implicit 0x0 value when explicit value is not given. It would be great to have a resetvalue together with resetmask tag.
 - Some bitfields are cleared by writing 0b0, some by writing 0b1. I do not know how to maintain that.

[Raven Claw]

Hi Brutte,

sorry for the long delay.
I will include your ATMega16 xml in 0.2.4.

• whats the sense in just listing fields ?
• listing cpu registers is not supported, if you really need it in one place with the memmory mapped registers, i could put it on the todo list, but dont expect this to be implemented soon.
• "It would be great to have a resetvalue together with resetmask tag"
  can you explain that ?
• "Some bitfields are cleared by writing 0b0, some by writing 0b1. I do not know how to maintain that"
  sounds to me like a write once register (write 1/0 to clear/set) W1C/W1S (these are not read, only written... so its displayed value is the reset value)
  could you write interpretations for the field like 00000001 00000010 ...if its 1 to clear ?
  some background: if you change a bit in a register, all its bits are written...
  so if you have a register that clears on writing 0, you could set a reset value of 0xFF and add interpretations like 11111110 11111101 ...

-Robert

[Brutte]

I was writing my answer for more than an hour and when I clicked "Post Reply" everything disappeared.
I am going slightly mad...

[Brutte]

Ok, so here I am once again:

I will include your ATMega16 xml in 0.2.4.

Thanks!

whats the sense in just listing fields

Registers, not fields.
For completeness of the layout. The user has to know that between K and M registers there is an L register, that it is included in the xml but accessing it causes some problems.

I could give you a detailed example of such "tough" registers but I have no idea which architecture you are familiar with. Yo have posted you do not use ARMv7M so perhaps AVR8 examples are better?

On AVR8 there are some peripheral registers that are not accessible by debugging dongles (even by original Atmel's debugging tools/IDE!), but fully accessible by the code of uC.

Readout through GDB->avarice->JTAGICEMk1->ATMega16 does not return valid value (at least for me). I do not know why (buffering? Wrong sequence of readouts?) but the EmbSys user has to know that:

• such register is included in xml layout (for completeness)
• that the readout is bogus, it is "under development" and that it is well known/reported
• it must not be written or read by GDB

That is why I suggest to add 'none' access feature that would just list register.

"It would be great to have a resetvalue together with resetmask tag" can you explain that ?

Some registers have known reset values and some don't. So if the register's reset value is unknown (like AVR8->PINA) and Embsys says its reset value is 0x00 then it is a bug and it is misleading.

That is why I suggest that a new tag "resetmask" must be added so that it masks known bits from unknown bits. I also suggest that it should be an AND mask so that bits set indicate known values.

Example:
AVR8->EECR(EEPROM control register)
"resetmask=0xFD" (0b 1111 1101)
"resetvalue=0x00" (or 0x02, whatever)
because second bit (EEWE) is unknown at reset.

"Some bitfields are cleared by writing 0b0, some by writing 0b1. I do not know how to maintain that" sounds to me like a write once register

IMHO you have used to few access rights. Embsys has 'r', 'w', 'rw' but there are many more required! 'rc_w1' or 'none'? Perhaps we could use a notation used by STM in their STM32 reference manuals:
r/w/rw/rc_w1,rc_w0/rc_r etc? I think it is quite consistent and intuitive.

[Raven Claw]

Here you can see what access types are implemented.

I guess this should be documented somewhere :-)

[Brutte]

I have updated the ATMega16 xml file (Flash+ EEPROM).

The EmbSys access rights lack RCW0:

Software can read as well as clear this bit by writing 0. Writing 1 has no effect on the bit value

That is the case with AVR8->MCUCSR where you cannot set but only clear bits.

I have also updated TIFR register/s for RW1C access (bit can only be cleared, by writing 1 to the field).

The granularity of the access rights is register-oriented, not field oriented and I cannot put valid access rights on fields with R and fields with RW located in one register (this is the case with UCSRA register)..

[Brutte]

So if the register's reset value is unknown (like AVR8->PINA) and Embsys says its reset value is 0x00 then it is a bug and it is misleading.

I was wondering, why does EmbSys include reset values at all? Is it because of some kind of compatibility?
I can imaging that adding all those masks, access rights, especially when reset values are displayed in hex (and some registers include several types of access rights in one word), would be very difficult/complicated/unreadable.
Do you think such "bare reset value" could be useful under some circumstances?

[Raven Claw]

it includes reset values because years ago when I designed the xml format, I looked through chip datasheets to find information about registers. And there I found reset values, and thought this could be interesting, because otherwise they would not be listed in the datasheets :-)

So I myself had no use for this information, but thought someone might.

-Robert

[Brutte]

I suggest that either tweak the reset values tagging( andmasks + all the access rights for specific bitfields) or remove resetvalue because currently this is a misleading information and as always it is better to have no information than the one that is misleading IMHO.

[Brutte]

• Description has changed:

Diff:

--- old
+++ new
@@ -12,3 +12,4 @@
 - If the reset value of a register is known, its value is given in an xml file (like for example DDRA is 0x00 at reset). If it is not, then it is not given (like PINA which has undefined value at reset). Unfortunately current EmbSys fills implicit 0x0 value when explicit value is not given. It would be great to have a resetvalue together with resetmask tag.
 - Some bitfields are cleared by writing 0b0, some by writing 0b1. I do not know how to maintain that.

+EDIT: New version of ATMega16 1v26 with EEPROM and Flash

[Brutte]

I have installed 2.5.r180 and I have noticed that in the ATMega16.xml you did not update the paths to dtd file after changing the structure...
I attach updated version 1v28.