Forum - MCS Electronics

 

FAQFAQ SearchSearch RegisterRegister Log inLog in

Bug when using more than 64k Flash on ATMega 1284P
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive
View previous topic :: View next topic  
Author Message
astroschmidt

Bascom Member



Joined: 04 Sep 2010
Posts: 33

blank.gif
PostPosted: Thu Apr 11, 2013 3:38 pm    Post subject: Bug when using more than 64k Flash on ATMega 1284P Reply with quote

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 )
Back to top
View user's profile
i.dobson

Bascom Expert



Joined: 05 Jan 2006
Posts: 1545
Location: Basel, Switzerland

switzerland.gif
PostPosted: Thu Apr 11, 2013 5:29 pm    Post subject: Reply with quote

Hi,

Sounds like a bug in Bascom with handling of rampz.

Do you see the same problem on real hardware?

Regards
Ian Dobson

_________________
Home of AVRTimer, the Bascom timer value calculator.
http://www.planet-ian.com

Walking on water and writing software to specification is easy if they're frozen.
Back to top
View user's profile Visit poster's website
astroschmidt

Bascom Member



Joined: 04 Sep 2010
Posts: 33

blank.gif
PostPosted: Thu Apr 11, 2013 6:51 pm    Post subject: Reply with quote

i.dobson wrote:
Hi,
Do you see the same problem on real hardware?


Yes.
As soon as I unremark the DATA lines the program behaves strangely.
It took me a long time to figure out, that it has to do with the >64k Flash and which function causes the faulty behaviour.

What I have found out, is that when a variable of type Word or Dword (probably also integer) is assigned to a variable of type Single, the result is always 0.

Kind regards

Roger
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Thu Apr 11, 2013 8:12 pm    Post subject: Reply with quote

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.

_________________
Mark
Back to top
View user's profile Visit poster's website
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Thu Apr 11, 2013 8:47 pm    Post subject: Reply with quote

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.
_________________
Mark
Back to top
View user's profile Visit poster's website
astroschmidt

Bascom Member



Joined: 04 Sep 2010
Posts: 33

blank.gif
PostPosted: Thu Apr 11, 2013 9:36 pm    Post subject: Reply with quote

albertsm wrote:
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.


Hi Albert,

I will try again the full program with real hardware and report.

Kind regards

Roger
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Thu Apr 11, 2013 9:42 pm    Post subject: Reply with quote

please use the program you posted. and also try the small code i also shown.
_________________
Mark
Back to top
View user's profile Visit poster's website
astroschmidt

Bascom Member



Joined: 04 Sep 2010
Posts: 33

blank.gif
PostPosted: Sat Apr 13, 2013 7:02 pm    Post subject: Reply with quote

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
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Tue Apr 16, 2013 10:15 am    Post subject: Reply with quote

thanks for testing. your report improved the simulator.
_________________
Mark
Back to top
View user's profile Visit poster's website
jene

Bascom Member



Joined: 03 Aug 2008
Posts: 13

germany.gif
PostPosted: Sat Aug 03, 2013 5:22 am    Post subject: Reply with quote

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
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Sat Aug 03, 2013 10:39 am    Post subject: Reply with quote

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.

_________________
Mark
Back to top
View user's profile Visit poster's website
jene

Bascom Member



Joined: 03 Aug 2008
Posts: 13

germany.gif
PostPosted: Sun Aug 04, 2013 11:00 am    Post subject: Reply with quote

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
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Sun Aug 04, 2013 10:47 pm    Post subject: Reply with quote

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.

_________________
Mark
Back to top
View user's profile Visit poster's website
njepsen

Bascom Member



Joined: 13 Aug 2007
Posts: 414

newzealand.gif
PostPosted: Mon Aug 05, 2013 11:51 am    Post subject: Reply with quote

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 .
_________________
Neil
Back to top
View user's profile
albertsm

Administrator



Joined: 09 Apr 2004
Posts: 5228
Location: Holland

blank.gif
PostPosted: Mon Aug 05, 2013 12:55 pm    Post subject: Reply with quote

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.

_________________
Mark
Back to top
View user's profile Visit poster's website
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.    www.mcselec.com Forum Index -> BASCOM-AVR Archive All times are GMT + 1 Hour
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum