16bit registers will not cooperate

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

I have tried to load the 16bit OCR registers in the timer 1, 2, of the mega162. they refuse to load, or erase the high byte. This phenomenon only happens when you set the WGMn2 and WGMn3 bits. This problem occurs with both the STK500 and the DRAGON. What is worse the avrstudio compiler refuses to load the registers for programming.

Calls to my local FAE from Atmel go unreturned.

I noticed in the KNOWN ISSUES section that avr studio seems to have problems with this. This is a major problem in my book.

Does anyone have a solution? I am using assembler, not 'c' for source coding

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Which portion you read or write first, the high or the low portion of the 16-bit register?

Are you sure you do both in correct order (i.e. the datasheet says which is correct) ?

- Jani

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

You need to write the high byte first, then the low byte (reverse this for reading).

You have a Dragon, so use JTAG to debug instead of relying on the simulator.

Regards,
Steve A.

The Board helps those that help themselves.

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

I tried, both methods with no luck

That's why I posted this

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Hi, timer 1 and 3 are 16-bit timers and timer 2 is 8-bit. How is WGMn0 and WGMn1 set? What do you want to do with the timers?
Mats

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

very simple PWM. I am using timer0 for something else, but with the timer1 being 16bit i can create very slow pulses. I am loading the high byte first, just like the data sheet says. I then setup the timers parameters(fast pwm #14/divide by 1024, etc.) As soon as I set eiter WGMn2 or WGMn3 the high byte goes to zero.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Here is the code I am using

.include "m162def.inc"

.def try =r16
.def tempa =r17
.org 0x00
Reset:
ldi try,high(ramend)
out sph,try
ldi try,low(ramend)
out spl,try
rjmp begin

begin:

ldi try,0xff
out ddrd,try
cli

ldi tempa,0xff
ldi try,0xff
out icr1h,tempa
out icr1l,try
ldi tempa,0xf0
ldi try,0xff
out OCR1aH,tempa
nop
out OCR1aL,try
ldi try,(1<<com1a1|1<<com1a0|1<<wgm11|0<<wgm00)
out tccr1a,try
ldi tempa,0x19
out tccr1b,try

done: rjmp done

Regards
Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I tried the code on a mega128 (the timer is the same as the mga162, at least as far as the functionality that you want) and it worked just fine.

Quote:
but with the timer1 being 16bit i can create very slow pulses.

How slow of a pulse do you want? With the code you have, if you are running at 1MHz, the PWM frequency is ~15Hz. Whether this is slow or not depends on your perspective.

Regards,
Steve A.

The Board helps those that help themselves.

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

Your reset vector is missing. Try this.

.include	"m162def.inc"

.org	0x00

		rjmp	Reset


.def	try	=r16
.def	tempa	=r17

Reset:
 	ldi		try,high(ramend)
	out		sph,try
	ldi		try,low(ramend)
	out		spl,try
	
	ldi		try,0xff
	out		ddrd,try
cli
	
	ldi		tempa,0xff
	ldi		try,0xff
	out		icr1h,tempa
	out		icr1l,try
	ldi		tempa,0xf0
	ldi		try,0xff
	out		OCR1aH,tempa
	nop
	out		OCR1aL,try
	ldi		try,(1<<com1a1|1<<com1a0|1<<wgm11|0<<wgm00)
	out		tccr1a,try
	ldi		tempa,0x19
	out		tccr1b,try

	done:	rjmp	done

RES

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

What possible difference could that make, RES? Why would not having a reset "vector" make 16-bit registers not co-operate? Why would adding an RJMP to the very next location cure any problems. Why would any vector but address 0 have any use in a program witout an SEI?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

At that point I was willing to try anythng. Further reading into the known issues explained that the simulator does not support the reading/writung of the 16bit registers. you have to physically do the math, then load the code into a micro and try it. What bugs the hell out of me is that even the dragon connected to the system and running in simulator does not work. I had to yank the section of code out of the main body, write it dedicated to a micro in an stk500 and scope it. Sure enough it worked!!

Rather disappointed that Atmel let something like this slide. I am going to retry with the Dragon and see if I goofed somewhere. Otherwise, I will chalk it up to experience and move on

Thanks to all who helped

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

theusch wrote:
What possible difference could that make, RES?

Because address 0x0000 is the reset via the external reset pin, por, bor, wd.

Quote:
Why would not having a reset "vector" make 16-bit registers not co-operate?

AVR must reset at 0x0000, else can start at the wrong vector and wrong things can happen.

Quote:
Why would adding an RJMP to the very next location cure any problems.

Looked like the program jumped direct into vector 0x0400, that is timer2 ovf interrupt.
The first program lines are 4 lines, then the rjmp at 0x400.

Quote:
Why would any vector but address 0 have any use in a program witout an SEI?

You mean he wants the AVR immidiatly jump into an interrupt vector? Don't understand last Q. :?

RES

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

RES,

As far as I can see, he is NOT using interrupts, so any vectors other than 0000 are not needed.

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

Res, you are full of pooh. A reset AVR starts executing the instruction at address 0. All the stuff you said is nonsense. Any instruction at 0 is carried out, then the next, etc.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Quote:
Looked like the program jumped direct into vector 0x0400, that is timer2 ovf interrupt.
The first program lines are 4 lines, then the rjmp at 0x400.

RES, in his code:

.org	0x00 
Reset: 
  ldi	 try,high(ramend)  ;this instruction is at address 0x0000
  out	 sph,try 
  ldi	 try,low(ramend) 
  out	 spl,try 
  rjmp	begin   ;this instructiion is at address 0x0004

begin: 

  ldi	 try,0xff  ;this instruction is at address 0x0005
...

And I don't know were you are getting 0x0400 from. The address of the timer2 overflow interrupt on a mega162 is 0x0016.

Quote:
You mean he wants the AVR immidiatly jump into an interrupt vector?

No, he means that the OP is not using interrupts, so the interrupt vectors are inconsequential.

Regards,
Steve A.

The Board helps those that help themselves.

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

I am not using interrupts. As I said before I could not get this simple code to operate. I found out tonight that the dragon merely emulates to the target system what the simulator does in the pc. Meaning, that since the simulator does not support the 16bit operations correctly the dragon won't either. I ran the final codebelow in the simulator only, and it did not work on the high bytes correctly. I then connected the dragon and ran the same code with the simulator on the target, and got the same results. I then simply programmed the target with the code and it ran just fine.

Here is the final code

;16bit timer1 operating in fast pwm mode #14.
;

;only use include when needed
.include "m162def.inc"

.equ pulseh =0xff
.equ pulsel =0xa0
.equ periodh =0x15
.equ periodl =0xff

;only use this section when needed!!
.org 0x00
Reset:
ldi r16,high(ramend)
out sph,r16
ldi r16,low(ramend)
out spl,r16
rjmp begin
;this is the actual code
begin:
ldi r16,0x80
sts clkpr,r16 ;enable the cpu clock to be divided
ldi r16,0x01
sts clkpr,r16 ;cpu clock divided by 2
ldi r16,0xff
out ddrd,r16
cli

ldi r16,(1<<com1a1|0<<com1a0|1<<wgm11|0<<wgm00)
out tccr1a,r16
ldi r17,periodh ;tempa and try set the time between pulses - 1.5 seconds
ldi r16,periodl
out icr1h,r17
out icr1l,r16
ldi r17,pulseh ;tempa and try set pulse width - 150msec
ldi r16,pulsel
out OCR1aH,r17
out OCR1aL,r16
ldi r16,0x1d
out tccr1b,r16

done: rjmp done ;this could also be a "ret" statement

Mind you this section is a part of a larger code. the rjmp line will be a ret statement

the include at the top of the code is omitted, as is the ramend section

Again, thanks to all who helped. I am taking this as a big learning experience

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

RES,

Any interrupt vector not being used can be filled with code.
If there is no interrupts program execution can start at 0x0 without any need to jump to "reset". Actually without the need for JMP or RJMP as first instruction, might as well be LDI or any logical instruction.
There is no need to have a label called "reset" in .asm program, it is just a convention.
You don't even need .org 0x0, processor will start at that location anyway after a reset.

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

Quote:
I am not using interrupts. As I said before I could not get this simple code to operate. I found out tonight that the dragon merely emulates to the target system what the simulator does in the pc. Meaning, that since the simulator does not support the 16bit operations correctly the dragon won't either. I ran the final codebelow in the simulator only, and it did not work on the high bytes correctly. I then connected the dragon and ran the same code with the simulator on the target, and got the same results. I then simply programmed the target with the code and it ran just fine.

If you use the JTAG functions of the Dragon, you aren't simulating anything. The code is running in the actual hardware.

Regards,
Steve A.

The Board helps those that help themselves.

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

Lennart wrote:
RES,

Any interrupt vector not being used can be filled with code.
If there is no interrupts program execution can start at 0x0 without any need to jump to "reset". Actually without the need for JMP or RJMP as first instruction, might as well be LDI or any logical instruction.
There is no need to have a label called "reset" in .asm program, it is just a convention.
You don't even need .org 0x0, processor will start at that location anyway after a reset.

Quote:
Res, you are full of pooh. A reset AVR starts executing the instruction at address 0. All the stuff you said is nonsense. Any instruction at 0 is carried out, then the next, etc.

I don't understand why vector 0 is called a reset handler. In every datasheet the examples show the rjmps.

RES

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

Because that's where the first opcode is fetched from at reset. It can be a JMP/RJMP (and probably should be if any interrupt vectors beyond it are being used) but it can actually be any of the opcodes that the AVR supports. It's just as valid for it to be "ldi try,high(ramend) " as anything else.

If you are not using the interrupt vectors then you gain all the space that would have been used for the vector table by just org'ing the actual program code at 0x0000 and not even wasting a word or two for an RJMP/JMP

Cliff

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

clawson wrote:
Because that's where the first opcode is fetched from at reset. It can be a JMP/RJMP (and probably should be if any interrupt vectors beyond it are being used) but it can actually be any of the opcodes that the AVR supports. It's just as valid for it to be "ldi try,high(ramend) " as anything else.

If you are not using the interrupt vectors then you gain all the space that would have been used for the vector table by just org'ing the actual program code at 0x0000 and not even wasting a word or two for an RJMP/JMP

Cliff

Ok, I see.

RES

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

Koshchi:
I connected the dragon via the JTAG, selected my platform as avrdragon and the device. When I run the code the registers did not display correctly, not did the part operate properly.

I have a call in to my local FAE locally to see what he says. Looking back I see that my original code posting was rather sloppy. The final 'masterpiece' is much better and as I said before with regard to the reset/rjmp stuff is that I was not getting anywhere and was willing to try anything. One thing we seem to be forgetting is that sometimes you have to do something that makes no sense in order to get the results we want.

Oh well,

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Quote:
In every datasheet the examples show the rjmps.
EXCEPT for chips with more than 8K flash which all show a JMP :)

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

To All:
I spoke to one of th Atmel FAE's, Jamie Hunter, great guy. He agreed with me that the simulator cannot support the 'older' mcu's with the temp register due to how things are dealt with internal to the chip. It has to do with the in and out statements. Newer devices no longet use the temp register and are now strictly accessed as memory locations with sts and lds.

As far as the dragon issue i came accross, he said I should retry it again. The dragon first loads the code into the chip and then simply acts as a translator between the micro and the pc.

I could have goofed, not the first time, will not be the last

Hope this is worthwhile info to anyone.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

What he didn't tell is that the Dragon DOES have bugs also :?

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:
I spoke to one of th Atmel FAE's, Jamie Hunter, great guy. He agreed with me that the simulator cannot support the 'older' mcu's with the temp register due to how things are dealt with internal to the chip. It has to do with the in and out statements. Newer devices no longet use the temp register and are now strictly accessed as memory locations with sts and lds.

Maybe not such a great guy, this is totally wrong. The temp register has nothing at all to do with in/out or sts/lds. The temp register is there to make sure that the writes and reads to the 16 bit registers are atomic. It is the same for every AVR with 16 bit timers, old and new. As far as I know, the simulator has this flaw for all AVRs with 16 bit timers as well.

However, the JTAG debugging does not use the simulator, it only uses the simulator's GUI. I tried your code on my Dragon with a mega16 and a mega169 (I don't have a mega162 available), and it worked flawlessly with both.

Quote:
I connected the dragon via the JTAG, selected my platform as avrdragon and the device.

Did you set this in the debugger set up dialog or just the programming dialog? They are two separate settings (the debugging is set in Debug/Select Platform and Device...).

Regards,
Steve A.

The Board helps those that help themselves.

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

Steve:
What he meant was that yes the temp register is there as you say to update the timer correctly. But Atmel originally did that to keep the coding simple by using in and out directives. The problem arises when the simulator tries to work with this. He informed me that since Atmel is packing more peripherals into the micros, a lot of them are now going to be addressed as memory locations using sts, or ld commands rather than in/out. He also confirmed that the simulator has this issue with all the 16bit peripherals.

In response to your second statement, YES I did configure both the debug platform, and the programmer separately. I did notice one thing that you should first configure the programmer, especially the fuses. I left the in circuit debug unchecked and I was no longer able to run the dragon for debugging. Simple answer is that the dragon downloads the code into the chip before debugging, so that means the config bits go as well.(DUHHHH)

I did say that I would retry the code with the dragon again. I am sure I goofed somewhere.

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Quote:

that means the config bits go as well.(DUHHHH)
Those bits DO NOT get changed in debug mode ie doing a "Build and Run" or "Start Debug".
So you basically set the clock fuses, the BOD, enable OCDEN, boot reset vector and size if any (I keep this as small as possible if no bootloader used) and leave this forever and nothing will change it unless you go into program mode and change the settings yourself.

By the way you may want to look at this to fill in the bits the FAE didn't tell you. :)
https://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=50435&highlight=stuffed

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

JS:
THis is exactly why the avrfreaks site is here!!

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user