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

[Philipp Burch]

Hi to everyone,

I've made some progress this weekend, tough I didn't come as far as I 
hoped. The libraries now build without errors or warnings and I am also 
able to compile and link the "simple" example. It needed more work than 
expected, so for example some changes to the linker file and to the .nut 
configs.
As mentioned previously, TI supplies the CMSIS for the Stellaris 
microcontrollers, so I now replaced the other header containing lots of 
#defines.

As TI seems to only distinguish between the LM3S and the LM4F families, 
there are now some family-specific files like lm3s.h. I'm not done yet 
with this separation however, so there are still files and preproc 
directives which only fit for the single device LM3S9B96.

I've uploaded my changes to http://hb9etc.ch/ethernut/ as three files:
- The complete Git repository containing all the files and changes so 
far. Simply unpack the archive, cd to the contained folder and run
git reset --hard
to get the working copy back.
- The new patch showing the changes from Subversion revision r4719.
- The updated simple.c which is supposed to simply blink the user LED on 
the design kit.

Anyway, the problem I'm facing now is that the controller seems to hit 
an unexpected interrupt or even an exception when running the example 
code. The end result is that the LED does not blink, but according to 
GDB the processor hangs in one of the endless loops found in 
cortex_init.c, namely in IntDefaultHandler(). If I comment the loop 
there, it looks like the CPU hits a BusFault, at least this is what 
GDB/OpenOCD says.

Could anyone give me a hint on what to do now? I couldn't figure out how 
to single-step through the program using GDB to find out where it enters 
the handler and I don't really know the way through all of the Nut/OS 
sources.

Oh, and please note that my changes to the linker file are not really 
based on extensive knowledge: I simply compared it to the STM32 variant 
and adjusted it until the linker did no longer complain. But I have no 
idea what these changes mean.

Thanks,
Philipp

On 10/12/2012 08:25 AM, Philipp Burch wrote:
> Hi Ole,
>
> On 10/11/2012 06:16 PM, Ole Reinhardt wrote:
> [...]
>>
>> - Your CPU header seem not to follow the "struct" way, like most other
>>     Cortex Mx CPU headers does. Yes we just had some long discussions
>>     about this. But as the STM32 and NXP port just started using this way
>>     and most other CPU vendors follow this way as well it would be a good
>>     idea to go the same way. Otherwise we will get in trouble with the
>>     common function that use
>>
>
> I just searched again and found another set of headers from TI. These
> are the CMSIS files and look very promising. I suppose that this is the
> way to go. Thanks for the hint!
>
> Philipp
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>
>