headers
William Wagner | 2 Nov 2010 12:26
Favicon

64 bit divides

Hello,

We are writing a small application whose size is around 16k. Looking at 
the map file/disassembler I see that approx 2k of the image is taken up 
by the functions __divdi3 and __udivdi3 (which come from the libgcc 
library).

I thought it seemed stupid that such a small and simple application 
should do any 64 bit divisions so I've looked into where they are used.

The first most obvious thing is that only the unsigned divide is ever 
used, __aeabi_uldivmod calls __gnu_uldivmod_helper which calls 
__udivdi3. __divdi3 and its helper __gnu_ldivmod_helper are never used 
and yet are not stripped out of the elf. Any easy way to fix that?

The unsigned divide is called in a few places, including in the diag 
print code. I thought I had previously seen a cdl option to 
enable/disable 64 bit print support but couldn't see any sign of one. 
Has anyone done this before? Are there any hidden issues with trying to 
remove 64bit printf support?

Thanks,
Will

--

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner <at> carallon.com
Development Manager                      Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul D. DeRocco | 2 Nov 2010 20:28
Picon

RE: 64 bit divides

> From: William Wagner
> 
> We are writing a small application whose size is around 16k. 
> Looking at 
> the map file/disassembler I see that approx 2k of the image 
> is taken up 
> by the functions __divdi3 and __udivdi3 (which come from the libgcc 
> library).
> 
> I thought it seemed stupid that such a small and simple application 
> should do any 64 bit divisions so I've looked into where they 
> are used.
> 
> The first most obvious thing is that only the unsigned divide is ever 
> used, __aeabi_uldivmod calls __gnu_uldivmod_helper which calls 
> __udivdi3. __divdi3 and its helper __gnu_ldivmod_helper are 
> never used 
> and yet are not stripped out of the elf. Any easy way to fix that?

I would expect that the signed divide would be much smaller, since it would
merely wrap the unsigned divide with some sign twiddling, so stripping it
might not help much.

If the only place this divide is used is in some non-critical code, another
approach would be to write your own version that uses a dumb
shift-and-subtract, so that the library version doesn't get linked in at
all. It should be possible to do it in a few dozen bytes of code, or maybe a
hundred if you write it in C.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
harish kasiviswanathan | 3 Nov 2010 03:03
Picon

Cyg_RealTimeClock constructor not getting called

Hi,

I am trying to develop a Freescale mx27 port of eCos. I have some of
the functionalities like RedBoot, Interrupts working. I am having
problem with Kernel real time clock. The function
cyg_real_time_clock() is returning 0. I also noticed that
Cyg_RealTimeClock constructor is not getting called.

Any help/ideas will be helpful.

Thanks.
Harish

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 1 comment |
headers
harish kasiviswanathan | 4 Nov 2010 15:14
Picon

Re: Cyg_RealTimeClock constructor not getting called

I found the problem. I am using older version of eCos as base for this
porting and compiler is arm-eabi-. So the problem occurred because
older eCos was built using arm-elf compiler. Arm-elf compiler supports
__CTOR_LIST__ (for the list of constructors) and arm-eabi supports
init_array.

On Tue, Nov 2, 2010 at 10:03 PM, harish kasiviswanathan
<harish.kasiviswanathan <at> gmail.com> wrote:
> Hi,
>
> I am trying to develop a Freescale mx27 port of eCos. I have some of
> the functionalities like RedBoot, Interrupts working. I am having
> problem with Kernel real time clock. The function
> cyg_real_time_clock() is returning 0. I also noticed that
> Cyg_RealTimeClock constructor is not getting called.
>
> Any help/ideas will be helpful.
>
> Thanks.
> Harish
>

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
Permalink | Reply | 0 comments |
headers
Alex Lindeijer | 4 Nov 2010 17:46
Favicon

DHCP and alarms

Hi
In case of switching from static ip to DHCP and plug out/in Ethernet we
call do_dhcp. We see that quite often the following ASSERT:
 ASSERT FAIL: <3>[410]cyg_callout_reset() Recorded alarm not in the
future! Starved network thread?
I make sure that no socket is sending data while Ethernet is down and no
IP address is acquired
In addition we some threads that ::cyg_thread_delay at the time of
acquiring DHCP IP address these threads never return from the
cyg_thread_delay() , ie keep on sleeping.

When I comment out in new_lease in dhcp_prot.c
cyg_alarm_initialize( lease->alarm, lease->t1, 0 );
    cyg_alarm_enable( lease->alarm );

I never get the assert and the threads return from sleeping. 

I see that no_lease , deletes the alarm, before a new is created. So
that should be OK. But in some way the enabling of the alarm cause the
assert and interferes with cyg_delay_thread

Thanks in advance for any hints
Alex Lindeijer | 3D perception AS
Senior System Designer

--

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Bowman | 9 Nov 2010 12:18
Picon

STM3210E crash

Has there been much success recently using an STM3210E-EVAL board?  I
seem to be having a few odd issues:

I have downloaded the toolchain, and also the tip-of-repository code
from eCosCentric.  I have built a set of libraries using the default
template, changing only the startup type from RAM (the default) to
ROM.  I assume that this will provide a binary which, when flashed to
the board, will cause the application to boot at power-up.  I have
also built the kernel tests - I am using tm_basic for most testing,
although I have the same issue with a hello_world style app that I
wrote.

I have used a SEGGER J-Link tool to flash the image, and then
monitored the output from the debug port.  The test starts OK  but
often halts midway through.  Enabling asserts is only slightly more
informative.  Often this is "Top/Base of stack corrupt", although I
have also seen "Scheduler lock == 0".  The point at which the crash
occurs can vary, although it rarely gets very far into the list of
timings before giving up.  It can occasionally run to test completion.

I haven't yet got the J-Link adapter sufficiently set up to provide
much useful insight into the internals (that may be the subject of a
subsequent email!).  It does at least appear to be correctly writing
the application to flash (via GDB and the J-Link gdb-server).  Can
anyone suggest what might be causing this series of crashes, or
recommend where to start when gathering more information?

I have also noticed a slightly odd piece of configuration data - the
default chip type for the board is listed as an STM32F103ZE, when my
board appears to have an STM32F103ZD.  The different is in the amount
(Continue reading)

Permalink | Reply | 5 comments |
headers
John Dallaway | 9 Nov 2010 13:15
Picon

Re: STM3210E crash

Hi Alan

Alan Bowman wrote:

> I have also noticed a slightly odd piece of configuration data - the
> default chip type for the board is listed as an STM32F103ZE, when my
> board appears to have an STM32F103ZD.  The different is in the amount
> of internal flash that the chip has available.  The configuration
> option never seems to be used anywhere as far as I can see.  I assume
> that it doesn't make much difference, provided my program is small
> enough to fit on the smaller flash.  Does anyone know if there are
> different versions of the eval board?

According to the user manual, the original STM3210E-EVAL board was
fitted with an STM32F103ZET6. I've not observed any stability issues
with this board when fitted with an STM32F103ZET6, but I've not used ROM
startup except for RedBoot.

The latest boards have an STM32F103ZGT6 which has 96kB internal SRAM. Ref:

  http://www.st.com/stonline/products/literature/um/14220.pdf
     (pages 1 and 47)

Some board vendors will fit alternative parts on request. Perhaps your
particular board has been customised?

I hope this helps...

John Dallaway
eCos maintainer
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Garnett | 9 Nov 2010 15:00
Favicon

Re: STM3210E crash

Alan Bowman <alan.michael.bowman <at> gmail.com> writes:

> I have also noticed a slightly odd piece of configuration data - the
> default chip type for the board is listed as an STM32F103ZE, when my
> board appears to have an STM32F103ZD.  The different is in the amount
> of internal flash that the chip has available.  The configuration
> option never seems to be used anywhere as far as I can see.  I assume
> that it doesn't make much difference, provided my program is small
> enough to fit on the smaller flash.  Does anyone know if there are
> different versions of the eval board?

If the ZD has less SRAM than the ZE then you will need to adjust the
location of the interrupt stack in the .ldi file. You need to change
the length of the SRAM section and the calculation for
hal_startup_stack. You should also make a similar adjustment in the
matching .h file.

In theory that is all you need to do, although it also means that the
data space available for applications will be smaller. You could also
experiment with reducing the size of the interrupt stack, which is a
little generous.

The platform HAL is designed with the assumption that all STM3210E
boards are fitted with the same part. The board is named the STM3210E
because it has a ZE in it after all. If this is no longer the case
then the HAL ought to be updated to reflect this. However, for now,
changing the .ldi file should be sufficient.

--

-- 
Nick Garnett                                      eCos Kernel Architect
(Continue reading)

Permalink | Reply | 2 comments |
headers
John Dallaway | 9 Nov 2010 15:11
Picon

Re: STM3210E crash

[ re-sending with copy to ecos-discuss ]

Hi Alan

Alan Bowman wrote:

>> Some board vendors will fit alternative parts on request. Perhaps your
>> particular board has been customised?
> 
> As far as I'm aware, this is a standard eval board.  The printing on
> the top of the chip clearly says ZD - I may investigate whether it's a
> printing error, rather than an alternative part.
> 
> It sounds like ROM startup is mainly used for Redboot to then load an
> application into RAM.  I'm trying to use as little RAM as possible,
> and don't need Redboot.  Am I correct in thinking that ROM startup
> mode for my application should be what I'm after?

The STM3210E-EVAL board is attractive for many developers because it
features sufficient (external) RAM to permit initial application
development in RAM. This generally allows a faster download/debug cycle
and provides greater flexibility in the use of breakpoints. However, I
would expect many production Cortex-M3 designs to feature no external
RAM, requiring a switch to ROM startup later in development in order to
reduce RAM usage.

For avoidance of doubt, you can use RAM startup without RedBoot by
disabling CYGSEM_HAL_USE_ROM_MONITOR.

I hope this helps...
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Bowman | 9 Nov 2010 17:29
Picon

Re: STM3210E crash

> If the ZD has less SRAM than the ZE then you will need to adjust the
> location of the interrupt stack in the .ldi file. You need to change
> the length of the SRAM section and the calculation for
> hal_startup_stack. You should also make a similar adjustment in the
> matching .h file.
>
> In theory that is all you need to do, although it also means that the
> data space available for applications will be smaller. You could also
> experiment with reducing the size of the interrupt stack, which is a
> little generous.

The ZD and ZE have the same amount of SRAM, 64kB.  This is correct in
the config files.  The ZD has 384kB of internal flash, whereas the ZE
has 512kB.  I have changed the .ldi and .h files for the ROM startup
type to reflect 384kB.

hal_startup_stack was set to be at start of SRAM+64kB.  Reducing the
64kB number didn't seem to help anything, but I'm not sure if it
should have done.  I also tried reducing the interrupt stack size in
my configuration from 4kB down to 2kB, but this also failed to help.

I have just built Redboot-ROM from the same set of libraries and
flashed it to the board and it appears to consistently boot correctly,
suggesting that the board itself should be OK.

Any ideas would be appreciated, particularly evidence that
applications built in ROM mode work/don't work on other people's
boards.

Thanks
(Continue reading)

Permalink | Reply | 1 comment |

Gmane