[En-Nut-Discussion] Ethernut on TI's Cortex-M3 (Stellaris LM3S...)

[Philipp Burch]

Hello Ole,

you're incredible :)

On 11/06/2012 12:59 PM, Ole Reinhardt wrote:
> Hi!
>
>> Yes, now I remember. :-)
>>
>> Quite strange, because dev_write_P should never appear when compiling
>> for ARM. And the compiler should throw an error, if someone tries to add
>> more members in the related variable initialization.
>
> Yes indeed very strange. I reviewed his code and could not find any
> obviously wrong initialisation.
>
> But what I observed is that nearly no USART driver correctly initialize
> the RINGBUF structs in the DCB (hopefully this should not matter).

Oh. Is there something which should be done differently? I mostly took 
the code from the LPC implementation.

>
> Anyway, when looking to philips GDB printout, it looks like the whole
> structure is moved by 4 bytes. I tried to figure out at which point
> (e.g. if one variable is missing) but for me it looks like the address
> of the whole struct was moved.
>
> Perhaps we are searching the wrong bug? Perhaps it is some kind of
> buffer-overflow anywhere?

I suppose this is unlikely. A buffer overflow would usually destroy part 
or all of the structure, but not simply move it by a few bytes.

>
> But as the device struct is a global variable it's address should not be
> changable, right?
>
> Could this be a linker problem?
>
> I compared the lm3s linker script with the linker script of LPC and CM3
> and found some minor differences. E.g. it does not contain a .ramfunc
> definition and places the .rodata at a different place. Could this
> result in such problems?
>
> I will create a new linker script based on the STM linker script and
> send it philipp for testing.

You got it. Against my expectation, I've got some time to test it. The 
updated script immediately solved the problem, now the 
printing_to_strings example works even with scanf() and httpd_simple 
starts fine. It obviously fails to initialize the ethernet driver, but 
all (debug) messages appear on the console and then the processor loops 
forever in the "error handler".

Thank you very much!

Cheers,
Philipp