Bug when using more than 64k Flash on ATMega 1284P

astroschmidt · Joined: 04 Sep 2010 Posts: 33

I may have found a strange bug, when more than 64k of the flash in an ATMega 1284P is used.

Look at the attached program, which is an excerpt of a very long program but where the bug already shows up.

$regfile = "m1284pdef.dat"
$framesize = 200
$swstack = 200
$hwstack = 200
$crystal = 20000000

Dim Float1 As Single
Dim Delta_phase As Dword
Dim Dds_constant As Dword
Dim Freq_ As Single
Dim F_irq As Dword

Freq_ = 1000
F_irq = _xtal / 256
Dds_constant = &HFFFFFFFF / F_irq
Float1 = Freq_ * Dds_constant
Delta_phase = Float1
End
DATA .........

When you uncompress the attached RAR-file and compile it the program at first uses less than 64k of the flash because at the end the second half of the DATA-lines is remarked.

If you simulate the program the variable "Float1" is correctly calculated as 5.4975E+7.

Now delete the "'(" and the "')" at the second half of the data lines (label: "White_noise_data:") and recompile.

The program now is bigger than 64k and if you simulate it the variable Float1 is suddenly 0???

Any idea if this is a real bug or if I oversee a stupid error of mine?

Remark: The (sometimes very long) DATA lines were calculated with Open Office Calc, then stored as a CSV-file then loaded into a text editor and from there copied into the BASCOM editor.

Kind regards
Roger
Now

(BASCOM-AVR version : 2.0.7.6 )

i.dobson · Posted: Thu Apr 11, 2013 5:29 pm Post subject:

Hi,

Sounds like a bug in Bascom with handling of rampz.

Do you see the same problem on real hardware?

Regards
Ian Dobson

astroschmidt · Joined: 04 Sep 2010 Posts: 33

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

when you need to include data, you can best use $inc , this way you do not need to paste in data.

the problem is an odd one : setting rampz to 0 before the statement, will fix the problem. Thus it is related to rampz. The odd part is that rampz is not used by the code (i only did a brief look).
So it could be a problem of the simulator. But since you tested with real hardware, it means that rampz not only forms a 24 bit register with the Z register for lpm/elpm, but also for data access !
And that i have only seen on XMega where this is handled.

A simple test would be :
dim var as byte

Rampz = 0 'set to 0
Loadadr Var , Z
ldi r24,1
st z,r24 ; store byte

Loadadr Var , Z
Rampz = 1 'different page
ld r24,z
sts {var},r24
print var

maybe you could test it?
I will have a look in the datasheet to see if there is a note about it. the rampz+Z 24 bit register is only usable when you can address >64kB of ram but the plain AVR chips can not address that space, so it is a bit odd.
just had a look and no info about it so if the above sample print 1 for var, it means the chip does not behave as it should.
i will have a look at the lib code, i might have overlooked something.

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

are you sure this problem exist in hardware? an ISIS simulation shown the proper value. I also checked the code and it is ok. I changed the simulator so it will not take RAMPZ into account for non-xmega chips. that was indeed a bug.

astroschmidt · Joined: 04 Sep 2010 Posts: 33

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

please use the program you posted. and also try the small code i also shown.

astroschmidt · Joined: 04 Sep 2010 Posts: 33

I tested again with real hardware and must admit, that the problem only exists with the simulator.
Sorry for the misinformation.
Memory doesn't seem to serve me as well as I'm approaching my 6th decade of life Smile

Kind regards

Roger

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

thanks for testing. your report improved the simulator.

jene · Joined: 03 Aug 2008 Posts: 13

Dear Albert,

I had the same problem but with an ATXMEGA128A4U, everytime my code exceeds 50% of memory usage my
variables have different values. I tested on real hardware, not with the simulator.

I have two 16bit AD-converter connected over SPI and if my memory usage will get over 50% the values have
a big deviation and not a stable value as if the memory usage is under 50%.

What can I do to fix it? My Bascom Version is the newest one 2.0.7.6

BR,
Jens

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

if you have read this thread you can see that this is not your problem. this case was a normal AVR where the SIM worked different compared to hardware. but in hardware there was no problem.
you use an xmega which does use rampz not only for code access but also for ram access.

if you have an ISR where you save the registers yourself, and you do not save RAMPZ, you can also have problems.
when you do not use NOSAVE, the compiler will handle it.

if you have a reproducible problem you can best send it to support.

jene · Joined: 03 Aug 2008 Posts: 13

Dear Mark,

first I need to say sorry that I mixed up your name and also forget the "s". It´s a little painful to me.
I am not sure if I can make some code where it is reproduceable, because my actual project is very big, but I will try it and send
it to support.

BR,
Jens

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

no problem i am used to be called Marc and Albert.
you can also zip and send the complete project to support. just include info about which line will give a bad result and i will check it.
no worry, we never look at the actual code , just at the lines related to the problem.

njepsen · Joined: 13 Aug 2007 Posts: 469

This also looks like the problem that I am also having with the 1284P when the memory use is over 50%. It is hard to get a handle on but the symptom I have is that the print#1 command ( data sent to a software uart) sends rubbish to the port - usually a whole heap of CR LF get sent .

albertsm · Joined: 09 Apr 2004 Posts: 5916 Location: Holland

that was already solved. i gave access to the beta but did not heard back?. that problem was very simple. the code contained an lpm where it should call a special lpm routine which increases rampz at a page boundary.
for some reason search on my project did not find all lpm code when i changed it many years ago.
but like i wrote before , this is different. it is likely the rampz gets a wrong value at some stage but i do not like guessing. i like some code to look at.