This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: STM32 ROM .bin does not start


Bernhard Gebert wrote:
> Sergei Gavrikov schrieb:
> >On Sun, Jan 03, 2010 at 01:57:46PM +0100, Bernhard Gebert wrote:
> >>Hello John,
> >>
> >>thank you for the hints.
> >>
> >>Now I modified the _rom.ldi and _rom.h, they look quite similar to
> >>those of the AT91SAM7S256 now.
> >
> >[snip]
> >
> >>I also deleted the RAM relocation from SROM to SRAM in
> >>hal_reset_vsr().
> >>
> >>But, still no success.
> >
> >Hello Bernhard,
> >
> >Have not success with..? The UART's output? As you did mention you did
> >bring up some _amateur_ hardware based on STM32 CPU, didn't you?  Did
> >you managed on your hardware the simplest application, well, like LED
> >flasher even without eCos? It would be great to know such things to do
> >futher brain storming activity.  Can you confirm that some downloaded
> >(or self built) flasher.{bin,hex} ran smoothly on your target. Had you
> >such a success with the same application(s) on your target?
> >
> >Sergei
> >
> >>Brg, Bernhard
> >
> Hello Sergei,
> 
> yes, I did some tests with my hardware:
> * read / write to flash memory
> * selfmade C++ project with gcc
> * UART1, some debug LEDs and CAN are working

So, you have working STM32 projects are built with GNU toolchain for
your HW, therefore you can compare the ld's scripts and the objdump's
outputs for the builds are built without and with eCos and take a look
on the eCos memory layout files as John pointed out again.

> further tests I've done: * built the same eCos examples for the
> AT91SAM7X256-EK (also homebrew hw), running correctly * now trying
> to toggle a debug LED in my tests to see something without the UART

Good to know, but that another target.

> As I went through the HAL's startup-code, I am quite sure that not
> even the function hal_reset_vsr() gets called. I can not set a debug
> LED inside at least.

Hm. Your quoted .ldi, .h mlt files look good to use the internal CPU's
resources only, but, what says arm-eabi-objdump for the final eCos ELF
build? Are there 0x0800_0000 and 0x2000_0000 origins only in the ELF?
Where are placed .data, .bss, startup stack segments, etc. You can
compare the dumps of the sections for working ELFs and for the got
ones with your tweaks those mlt files. Of course a working JTAG engine
would be so helpful for digging until we can not drive a LED.

Sergei

> Brg,
> Bernhard

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]