BUS Error: M5325EVB project from last year does not run with CW6.3

[fwprivus]

Hi,

I have a nice project which I used for demonstrations all over last year.

When I opened it with Codewarrior v6.3, it got automatically converted.

A.
First I have to note, that I had a hard time, getting it built. I had to
(a)
undef severals 'inlines' to circumvent compiler errors, and myriads of

(b)
implicite type conversion errors (s.th. like "from * __regabi to *") forced me to undef the MAPI and _MAPI macros.

However now it builts without error. It is a little bit unhappy, since I had to change sources which I were not supposed to do.

B.
This is my persisting problem:
If I download and run the project it stops very early within system initialization, much before getting to main, with a "Bus Error". It is somewhere near copying ROM data. (However it is a RAM project: everything is loaded into the on-chip and on-board RAMs. )

I had similar problems in the past with a MCF54xx project. Some __S_romp arithmetics in the Linker cfg file (stupid non-reproducible trial and error) helped me that time. This time I am not that happy.

Do you have any advice?

Thanks.

[Black]

Since this issue requires further investigation I recommend submitting a service request at (click on Submit a service request):

http://www.freescale.com/webapp/sps/site/homepage.jsp?nodeId=054670

Please attach an example project with this issue and your CodeWarrior Help->About...->Installed Products->Save as text file.

Also please note that the current version of CodeWarrior for ColdFire is 6.4 available for download at:

http://www.freescale.com/webapp/sps/site/overview.jsp?nodeId=01272694014080

Your CW 6.3 license.dat file should work also in the 6.4 version. Please copy it in the CW 6.4 installation folder. Also please install this 6.4 version in a new folder as you can have several CodeWarrior installations on the same computer and let us know if the issue continues in CW 6.4.

Thank you.

Best regards,

D

[fwprivus]

Thanks for your answer.

I think I know the problem (and know how to work around it by avoiding the AT clause in the locator control file).

I guess there is a mess (WRT v4->v5->v6) in regarding how locator labels get their address in sections which have different p_addr and v_addr. I got the impression (but I had to re-verify it) that even the meaning of physical address and virtual address was interchanged on the course of v4->v5->v6 - this makes it even more confusing.

The problem is quite general:

Locator labels do not seem to have a 'storage qualifier' which assigns to them either the physical address or the virtual address.

With my Linker v6.3
- physical address is, where the objects are stored in memory (ROM),
- virtual address is the location, where they will be accessed from (after copying in the initialization, RAM).

Labels within sections with virtual memory get the virtual memory address assigned:

.appcode :
{
   *(.text);
  * (rodata);
   endofappcode = .; // v_addr == p_addr, since no AT()
} > MYROM

   ANCHOR = endofappcode;

.inidata : AT(0x10000) // virtual memory at 0x10000
{
   vLABEL = .; v_addr != p_addr, vLABLE points to v_addr
   *(.data);
   *(.sdata);
} >> MYROM // physical memory

   OFFSET = sizeof(.inidata);

# I am now avoiding AT() to obtain a label with a physical address:

.romp :
{
   . = . + ANCHOR + OFFSET; // manually advance the p_addr location pointer !?!?
   _S_romp = .; // p_addr, since v_addr == p_addr
   WRITE(...);
   ...
} >> MYROM // physical memory

If I have more time in a few days, I will revise it with 6.4 and send a problem report.

Thanks and regards,
Frank

[fwprivus]

dito