View previous topic :: View next topic |
Author |
Message |
astroschmidt
Joined: 04 Sep 2010 Posts: 33
|
Posted: Thu Apr 11, 2013 3:38 pm Post subject: Bug when using more than 64k Flash on ATMega 1284P |
|
|
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 |
|
|
i.dobson
Joined: 05 Jan 2006 Posts: 1570 Location: Basel, Switzerland
|
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 _________________ Walking on water and writing software to specification is easy if they're frozen. |
|
Back to top |
|
|
astroschmidt
Joined: 04 Sep 2010 Posts: 33
|
Posted: Thu Apr 11, 2013 6:51 pm Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Thu Apr 11, 2013 8:12 pm Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Thu Apr 11, 2013 8:47 pm Post subject: |
|
|
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 |
|
|
astroschmidt
Joined: 04 Sep 2010 Posts: 33
|
Posted: Thu Apr 11, 2013 9:36 pm Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Thu Apr 11, 2013 9:42 pm Post subject: |
|
|
please use the program you posted. and also try the small code i also shown. _________________ Mark |
|
Back to top |
|
|
astroschmidt
Joined: 04 Sep 2010 Posts: 33
|
Posted: Sat Apr 13, 2013 7:02 pm Post subject: |
|
|
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
Kind regards
Roger |
|
Back to top |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Tue Apr 16, 2013 10:15 am Post subject: |
|
|
thanks for testing. your report improved the simulator. _________________ Mark |
|
Back to top |
|
|
jene
Joined: 03 Aug 2008 Posts: 13
|
Posted: Sat Aug 03, 2013 5:22 am Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Sat Aug 03, 2013 10:39 am Post subject: |
|
|
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 |
|
|
jene
Joined: 03 Aug 2008 Posts: 13
|
Posted: Sun Aug 04, 2013 11:00 am Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Sun Aug 04, 2013 10:47 pm Post subject: |
|
|
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 |
|
|
njepsen
Joined: 13 Aug 2007 Posts: 469
|
Posted: Mon Aug 05, 2013 11:51 am Post subject: |
|
|
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 |
|
|
albertsm
Joined: 09 Apr 2004 Posts: 5920 Location: Holland
|
Posted: Mon Aug 05, 2013 12:55 pm Post subject: |
|
|
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 |
|
|
|