[Bug 1001814] Kinetis clock gating

[bugzilla-daemon@bugs.ecos.sourceware.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.