This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001814] Kinetis clock gating
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Sun, 07 Apr 2013 05:39:02 +0000
- Subject: [Bug 1001814] Kinetis clock gating
- Auto-submitted: auto-generated
- References: <bug-1001814-104 at http dot bugs dot ecos dot sourceware dot org/>
Please do not reply to this email, use the link below.
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001814
--- Comment #19 from Mike Jones <mjones@linear.com> ---
I worked though patches one by one until a problem was found with Ilija's help.
I was using the diag for shell IO rather than tty3, and this caused a problem.
Diag polls and that used up much of the CPU. That exposed a SPI bug that caused
a loop on status to never complete. Ilija created a patch for that. That got
most of my application up.
I am now down to one problem. A malloc no longer works. Here is what my heap
and stack look like:
STACK
-----
thread pri base size used percent state name
1 31 0x1fff6418 2048 260 12.7 0 Idle Thread
2 4 0x1fff1808 2048 1484 72.5 16 setup_thread
3 5 0x1fff2008 2048 336 16.4 1 alert_thread
4 6 0x1fff2a08 2048 792 38.7 1
telemetry_monitor_thread
5 7 0x1fff2808 512 212 41.4 1
telemetry_thread
6 10 0x1fff3208 4096 1588 38.8 0 shell_thread
7 11 0x1fff4208 1024 660 64.5 16 network_thread
8 8 0x1fff9a08 4096 644 15.7 1 tcpip
9 4 0x1fffaa08 4096 188 4.6 1 eth
10 7 0x1fff460c 2048 384 18.8 1 telnet
11 7 0x1fff4e0c 2048 336 16.4 1 ftp
12 7 0x1fff560c 1024 480 46.9 1 snmp
HEAP
----
arena 26464
fordblks 13756
fsmblks 0
hblkhd 0
hblks 0
keepcost 0
maxfree 13756
ordblks 1
smblks 0
uordblks 12688
usmblks 0
My malloc statement:
hex_data = (char*) malloc(17000);
Then down in dlmalloc.cxx
remainder_size = long_sub_size_t(chunksize(top), nb);
if (chunksize(top) < nb || remainder_size < (long)MINSIZE)
{
diag_printf("chunksize(top)=%ld, nb=%d, remainder=%ld\n", chunksize(top),
nb, remainder_size);
MALLOC_UNLOCK;
CYG_MEMALLOC_FAIL(bytes);
return NULL; /* propagate failure */
}
This returns null. The diag print displays:
chunksize(top)=13776, nb=17008, remainder=-3232
I tried to turn on the debug build, but I get the following ASSERT:
ASSERT FAIL: <1>thread.inl[186]void Cyg_HardwareThread::attach_stack() Stack
size too small
ASSERT FAIL: <1>thread.inl [ 186] void
Cyg_HardwareThread::attach_stack()
l
I tried to increase the idle thread stack size but could not get by this. If
anyone knows how to make the debug work, that might help me get data.
If I have to guess, the Doug Lea malloc has some chunk size, and no malloc
bigger than will work.
At this point in the game, my code and ecc file are very close to what used to
work. I only tweak a line related to a different parameter order in a GPIO
call. And the ecc is the same other than the new stuff from the patches. 26K of
heap is what I had before all this was patched.
When I diff'ed my ecc file with the old one, I find no differences related to
malloc settings.
I notice there is a fall back heap size
CYGNUM_MEMALLOC_FALLBACK_MALLOC_POOL_SIZE of 16384. If this is the heap size,
my request would fail. But my print out of the heap says it is 26K. So I
believe the heap is externally defined.
I looked around and did not find any settings in the config tool to set the
block size. I don't have time to learn how the malloc works at the moment. I
suppose it is possible the chunk size is calculated and sensitive to space or
some subtle change from these patches.
Bottom line for now is, the whole application seems to work other than this
large malloc. Therefore, committing the code would break my app unless I
rewrote this section to work in smaller chunks. That would be a lot of work
given the way the code works, but I can't elaborate on this code. It is a very
complex data processing algorithm that would be hard to make work in chunks,
especially with my project deadlines.
--
You are receiving this mail because:
You are on the CC list for the bug.