Would you like to react to this message? Create an account in a few clicks or log in to continue.

You are not connected. Please login or register

PC on AVR seems to be correct

2 posters

Go down  Message [Page 1 of 1]

1PC on AVR seems to be correct Empty PC on AVR seems to be correct Sat Jun 19, 2021 7:30 pm

TimFisch

TimFisch

I tried a simple c code on AVR 328, to toggle a pinout. The compiled code works fine, however the Program Counter seems to be wrong. It shows 0x0048 / 0x0049. In the hex file this is within the interupt table. I thought it should be somewhere between 0x0086 and 0x009a...

Code:

#define F_CPU 8000000UL

#include <stdio.h>
#include <avr/interrupt.h>
#include <util/delay.h>

#define SET_BIT(PORT, BIT)  ((PORT) |=  (1 << (BIT))) // Set Port-Bit
#define CLR_BIT(PORT, BIT)  ((PORT) &= ~(1 << (BIT))) // Clear Port-Bit
#define TGL_BIT(PORT, BIT)  ((PORT) ^=  (1 << (BIT))) // Toggle Port-Bit

int main(void)
{
  SET_BIT(DDRD, PORTD1);
  while (1)
  {
    TGL_BIT(PORTD, PORTD1);
     _delay_us(50);
  }
}



PC on AVR seems to be correct Hexfil10

https://wiki.mexle.hs-heilbronn.de/

2PC on AVR seems to be correct Empty Re: PC on AVR seems to be correct Sat Jun 19, 2021 10:09 pm

arcachofo

arcachofo

The problem with this is that an AVR Program Memory location is 16 bits wide.
And PC stores PM addresses, no byte positions.
So whem PC=0x0048, it is pointing to PM address 0x0048 which occupies bytes 0x0090 and 0x0091 (if we count bytes).

There is not such division in bytes in AVR PM.
But hex addresses are based in bytes and in the case of AVR this does not match PM addresses.

3PC on AVR seems to be correct Empty Re: PC on AVR seems to be correct Sat Jun 19, 2021 10:26 pm

TimFisch

TimFisch

Ok, that "solve" my misunderstanding. The wrong interpretation arose, because the debugger I know, use the byte representation (e.g. in Microchip Studio or MPlab X).
Also the "code.lss" assembler output files of the compiler uses the byte-wise addressing. For debugging it might be better to have this byte address representation.

For my personal taste, this also applies for the flash monitor. It's hard to see ASCII Text stored there.

https://wiki.mexle.hs-heilbronn.de/

4PC on AVR seems to be correct Empty Re: PC on AVR seems to be correct Sun Jun 20, 2021 2:02 am

arcachofo

arcachofo

Yes, byte address representation is widely used and the flash monitor used bytes in the begining, but I changed it to the size of the instruction for each MCU.

The real value of PC is a program address.
But it is indeed useful having the byte address at hand, I will add it.

It's hard to see ASCII Text stored there.
I'm not sure about this...
How are ASCII values actually stored in Program Memory?
One value per PM location or 2 values per PM location?
Do you have an example at hand?

5PC on AVR seems to be correct Empty Re: PC on AVR seems to be correct Sun Jun 20, 2021 4:04 am

TimFisch

TimFisch

Here is an example - it does not make much sense, but it will store some ASCII text in PM (at least on the optimization level of my compiler).
The 8bit stored text is visible.

Code:

#include <avr/pgmspace.h>
const char str[] PROGMEM = "just some test with more characters in order to see something";

int main(void)
{
 int i=0;
 int a=0;
 while (a!=1) {
 i++;
 a =str[i];
 }
}

PC on AVR seems to be correct Hexfil11

https://wiki.mexle.hs-heilbronn.de/

6PC on AVR seems to be correct Empty Re: PC on AVR seems to be correct Sun Jun 20, 2021 1:37 pm

arcachofo

arcachofo

Here is an example - it does not make much sense, but it will store some ASCII text in PM (at least on the optimization level of my compiler).
The 8bit stored text is visible.
Yes, definetly individual bytes can be accessed.
I had a look and indeed LPM instruction directly addesses bytes in program memory.

I'm guessing what happens with program memories that are <16 bits like PIC14 family.

Anyway this needs a solution.

Sponsored content



Back to top  Message [Page 1 of 1]

Permissions in this forum:
You cannot reply to topics in this forum