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

[Uwe Bonnes]

>>>>> "Philipp" == Philipp Burch <phip at hb9etc.ch> writes:

    Philipp> Hi to everyone, I've made some progress this weekend, tough I
    Philipp> didn't come as far as I hoped. The libraries now build without
    Philipp> errors or warnings and I am also able to compile and link the
    Philipp> "simple" example. It needed more work than expected, so for
    Philipp> example some changes to the linker file and to the .nut
    Philipp> configs.

The magical factor of three between the time allocated and the time used..

    Philipp>   As mentioned previously, TI supplies the CMSIS for
    Philipp> the Stellaris microcontrollers, so I now replaced the other
    Philipp> header containing lots of #defines.

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

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

Some nitpicking first:
- nut/arch/cm3/dev/lm3/lm3s_clk.c seems TI supplied. Put it under vendor.
- Your repository mixes CR/LF and LR line endings.  E.g.

diff --git a/nut/arch/cm3/dev/lm3/system_LM3S.c b/nut/arch/cm3/dev/lm3/system_LM3S.c
index fac3162..96d8848 100644
--- a/nut/arch/cm3/dev/lm3/system_LM3S.c
+++ b/nut/arch/cm3/dev/lm3/system_LM3S.c
@@ -47,7 +47,7 @@
 // will be configured according to the macros in the rest of this file.
 // If it is defined to be 0, then the system clock configuration is bypassed.
 //
-#define CLOCK_SETUP 1
+#define CLOCK_SETUP 0^M
                     ^^^^
                     here or
diff --git a/nut/arch/cm3/dev/lm3/system_LM3S.c b/nut/arch/cm3/dev/lm3/system_LM3S.c
new file mode 100644
index 0000000..8eb8393
--- /dev/null
+++ b/nut/arch/cm3/dev/lm3/system_LM3S.c
@@ -0,0 +1,616 @@
+/*********************************************************************//**^M
+ * @file     system_LM3S.c^M

here. 

You probably also forgot to add the lm3XX.conf file you work with.

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

You access some not-existing memory. Try to single step through your
program, if you don't have anything else under suspect.

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

I assume a gdb like debugger and a gdb-server like setup.

Compile your program and libraries with -O0 for linear flow and with -g

>st-util&
>arm-none-eabi-gdb xxx.elf
>>tar ext :4242( or whatever your debugger, my example is STLINK)
>>b NutInit
>>load
>>c

Now you should be in arch/cm3/os/nutinit.c: NutInit
>> b main
>> c

If you now are in main, the illegal memory access happens in your user
code. Now use single stepping
>> s
to find the root of the problem.

If the problem happens early in your setup, I suspect some problem in the
clocksetting. Try to set breakpoints there.

To print out e.g. the sysctl structure, use
>> p /x *((SYSCTL_Type*)0x400FE000

...

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------