CW 7.0 C++; MCF52223EVB; Will Pay for Help In Getting Started

[nevilleb]

Hello,

We're much behind schedule on a project and Freescale tech support was helpful in the beginning but we're totally stuck and freescale support seems to have fallen off the map and we can't wait any longer.  I've programmed microcontrollers in the past but am a bit rusty and am having a bit of trouble starting.

We're willing to pay someone to help us out in any or all of the following areas, preferably in the following order:
1) Get the code attached to this post to not give a runtime error (see below) (estimated 1-2 hours?)

2) Assist with other configuration/linker/runtime issues as needed; we're porting a small c# program to run on the MCF52223 in c++ (estimated at 10-30 hours)

3) Help write a routine to read 2 ADC ports

If you'd like to help us out on this issue out of the goodness of your heart, please just reply to this post.  If you'd like us to pay you for your help, please email me at nevilleb@innovativedrive.com with your hourly rate and resume.  Then, we can talk briefly by phone to make sure there's a fit and I'll send you an NDA and I9 and we can send you the full code and get started.

Thank you, in advance, for any help you can offer,

Neville

---------------------------------------

This is a follow-up to SR 1-432245806:

I am trying to build the attached project and am getting a run-time error when I try to run the program on the M52223EVB. Apparently it is related to a some kind of memory bug in CW related to the 'new' operator.

I received the advice listed below about how to work around the problem but do not understand the advice. Can you please provide an example using the attached project?

Thank you,
Neville

------------------------
In reply to your message regarding Service Request SR 1-432245806:

Unfortunately there is no work around by now, but the bug should
appears fixed in the next release build of the Codewarrior, it is on schedule
to appears next July 2008. My recommendation to this issue is don´t
create long allocation in the memory this is the major issue here, also
you can try to modify from the linker file the heap for the stack,
maybe it can help, also try to use the alignment structure as byte.

Hope it helps and thanks for the bug catch.

I will pass this Service request to the developers team, please if you
need follow up open a new Service Request.

MC_PC_Test5.zip

Message Edited by t.dowe on 2009-10-29 09:40 AM

[nevilleb]

I received the following response today from Freescale:

"In reply to your Service Request SR 1-435326464:

I apologize for the delay in response, This bug still with out fix, and
unfortunately there is no work around for the moment, the main problem
is the new operator, and codewarrior is corrupting the alignment
memory allocation when this operator is called,  The developer team
suggested to avoid to use the new operator, until the bug appears fixed. The
bug will appear fixed in the next build of the Codewarrior 7.0v on
schedule to appears public in july 2008.

I apologize for all these inconveniences causing you, but we want to
thank you for catch this catastrophic mistake in the C++ compiler."

I don't understand how a C++ compiler can be released where the 'new' operator does not work.  How do I "avoid use of the 'new' operator"?  How else do I create new objects?  Does anyone have any suggestions as to where to go from here?

Thanks,

Neville

Message Edited by nevilleb on 2008-05-09 05:58 AM

[RichTestardi]

Hi Neville and others...

I was able to reproduce the bug, but unfortunately it seems I cannot rebuild C++

with my "Special Edition" free version of CodeWarrior...

But I noticed something that might or might not be significant...

It seems (assuming I can properly debug the project you built) nobody is calling

alloc.c:init_alloc() prior to calling the other alloc.c functions...

Could this just be an initialization bug?  Does someone out there know how

that routine is called, and if it really needs to be (as the comment says)?

Thanks.

(Also, does anyone know if there is any way to compile C++ with a free version

of CodeWarrior?)

-- Rich

[RichTestardi]

Hi again,

Sorry, I spoke too soon...

Yes, init_alloc() is being called...  I somehow missed it the first time.

I think the real problem is your use of "fixed" memory pools...

If I set a breakpoint here in alloc.c:__pool_allocate():

#if _MSL_USE_FIX_MALLOC_POOLS
 if (size_requested <= max_fix_pool_size)
  result = allocate_from_fixed_pools(pool_obj, size_requested, size_received);
 else
#endif /* _MSL_USE_FIX_MALLOC_POOLS */
  result = allocate_from_var_pools(pool_obj, size_requested, size_received);

And force it to never use the fixed pool, you're fine and your program succeeds (well, it loops forever :smileyhappy:.

You could recompile msl with _MSL_USE_FIX_MALLOC_POOLS set to 0 and that would achieve your goal.  I'm sure someone here can tell you how to do that (I don't use msl).  Unfortunately, max_fix_pool_size is a constant, so I think a recompile of msl is required.

I believe the real problem is that each fixed pool uses 4k of memory...  And there are *5* fixed pool sizes!  You have your heap set to 4k total!  So the first pool size you allocate (8 bytes) succeeds, and the second one (16 bytes) fails.

Fixed pools make no sense on a processor with 32k of total memory.

From the MSL C Reference:

_MSL_USE_FIX_MALLOC_POOLS For tiny allocations, fixed sized pools help

significantly speed allocation/deallocation, used

only with the modern memory pooling scheme.

You can reserve a pool for a small range of

sizes. The use of fixed sized pools can be

disabled by setting

_MSL_USE_FIX_MALLOC_POOLS to 0. The

default value is 1. Use of fixed size pools

requires further configuration. The current

shipping configuration is:

1. Each pool will handle approximately 4000

bytes worth of requests before asking for more

memory.

2. There are 4 pool types. Each type is

responsible for a different range of requests:

a. 0 - 12 bytes

b. 13 - 20 bytes

c. 21 - 36 bytes

d. 37 - 68 bytes

Requests for greater than 68 bytes go to the

variable size pools. The number of types of pools

is configurable below. The range of requests for

each type is also configurable.

[RichTestardi]

Also, I believe Mark's utasker just added support for ADCs for the MCF52223, as another avenue to explore to get you up and running quicker...

  http://www.utasker.com/

Mark wrote:

SP 7 - New: Various hardware interfaces for simple and powerful interrupt based PIT, DMA Timers and ADC control, including simulation of these modules. An ST SPI FLASH driver, specific project support for M5221X and M5222X parts, as well as more flexible PLL configuration and improved power management - for full details see the service pack notes