ALE toggles when XRAM is enabled!

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

Yes, I know that that's the idea, to toggle ALE pin in every XRAM access.
As ATmega162 datasheets states, when the XRAM interface is enabled, there is activity on pins: ALE, portA and portC while not on WR and RD pins, on every RAM access, internal or external.

Even though I don't like this, I must live with it.

The problem is that in the bellow piece of code there is ONE instruction that seems to access RAM but none of them should access RAM according datasheets and my own logic!!!

I am absolutely sure that something happens in that piece of code with ALE pin because I've done testing and measurements with a universal counter which show me that ALE pin toggles once in every MainLoop.

It could be the instructions which access portB and portD but then ALE should toggle, 2 or 4 times, not only 1.

This problem does the direct use of FRAM in AVR's XRAM interface(like the design note here suggests) not a good practice, since it destroys FRAM in a short time unless you put the AVR to sleep often enough.

Anyway, can you spot the guilty instruction?????

;----------------------------------------------------------------
MainLoop:
cpi temp2,$55
DoNotEWDR: brne DoNotEWDR
DoEWDR: sbi portB,MISO ;Do EWDR.
nop
nop
nop
nop
cbi portB,MISO

ldi data,$55

cbi portD,LED

ldi temp1,50

mov DelayL,Temp1 ;1---\ | 172 2sec
Delay1L: mov DelayM,Temp1 ;1 \ | 200 3sec
Delay1M: mov DelayH,Temp1 ;1 \ | 252 6sec
Delay1H: ; \
dec DelayH ;1 \ Delay (cycles):
brne Delay1H ;1/2 /
dec DelayM ;1 / 3*Temp1+
brne Delay1M ;1/2 / +3*Temp1^2+
dec DelayL ;1 / +3*Temp1^3+
brne Delay1L ;1/2-/ +Temp1^3(with nop)

sbi portD,LED

ldi temp1,50

mov DelayL,Temp1 ;1---\ | 172 2sec
Delay2L: mov DelayM,Temp1 ;1 \ | 200 3sec
Delay2M: mov DelayH,Temp1 ;1 \ | 252 6sec
Delay2H: ; \
dec DelayH ;1 \ Delay (cycles):
brne Delay2H ;1/2 /
dec DelayM ;1 / 3*Temp1+
brne Delay2M ;1/2 / +3*Temp1^2+
dec DelayL ;1 / +3*Temp1^3+
brne Delay2L ;1/2-/ +Temp1^3(with nop)

jmp MainLoop
;---------------------------------------------------------------

Kyriakos

Practice Safe hex.

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

Without your variable declarations it's kinda hard to follow what you're doing here.

admin's test signature
 

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

You don't need to understand what the program does. Just look at the instructions. Which one could, in your opinion, access RAM, internal or external?

There is the list with the instructions which are used in the above code:

cpi
brne
sbi
nop
cbi
ldi
mov
dec
jump

Kyriakos

Practice Safe hex.

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

Hi,

Also where do you enable the XRAM interface?

Its possible it is just some internal logic accessing the SRAM, the best way would be to start commenting out instructions until it stops....

-Colin

PS: The FM18L08 device has unlimited endurance....

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

Thanx Colin,
I didn't see that model. I am currently using FM1808 which has only(!) 10 billion access cycles.
FM18L08 has unlimited cycles but doesn't work with 5V which I prefer.
Anyway I'll see what I'll do about it.

XRAM and others inits are taking place in the start of the program. Only this piece of code runs continusly and causes ALE to toggle.

Yet, the question remains...
Starting removing instructions...

Kyriakos

Practice Safe hex.

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

Flashing a LED with cbi/sbi caused ALE toggling!!!
I think it's because of the relative "huge" amount of current the LED requires(@ 5V with a 4K7 resistor in series).
What can I say???

Kyriakos

Practice Safe hex.

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

Perhaps you could say that your universal counter is a bit more
sensitive to glitches (no, not you Mark) and records lower levels than
ordinary logic.