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

[Harald Kipp]

Hi Philipp,

On 05.11.2012 23:18, Philipp Burch wrote:
> 
> So obviously there is an offset of one pointer (4 bytes) in the
> structure. When comparing the map files, the structure is located at
> 0x200001d0 for the working example (without scanf()) and at 0x200001d4
> when it's wrong.

Just a few hints, unfortunately nothing specific:

That _may_ be caused by a difference in the structure between Harvard
and non-Harvard architectures. The former includes an additional member
dev_write_P, which allows them to write data from program space.

struct _NUTDEVICE {
    NUTDEVICE *dev_next;
    char dev_name[9];
    uint8_t dev_type;
    uintptr_t dev_base;
    uint8_t dev_irq;
    void *dev_icb;
    void *dev_dcb;
    int (*dev_init) ();
    int (*dev_ioctl) ();
    int (*dev_read) ();
    int (*dev_write) ();
#ifdef __HARVARD_ARCH__
    int (*dev_write_P) ();
#endif
    NUTFILE * (*dev_open) ();
    int (*dev_close) ();
    long (*dev_size) ();
};

For ARM targets, __HARVARD_ARCH__ must not be defined and dev_write_P
must not be included in the structure.

However, more likely this looks to me like a problem with alignment. I
remember, that the Cortex branch initially contained

 #elif defined(__CORTEX__)
 #define NUTMEM_ALIGNMENT        2
 #elif defined(__arm__)
 #define NUTMEM_ALIGNMENT        4

in sys/types.h. First problems had been detected in IP checksum
calcualtions and it had been changed to

 #elif defined(__CORTEX__)
 #define NUTMEM_ALIGNMENT        4
 #elif defined(__arm__)
 #define NUTMEM_ALIGNMENT        4

Btw.

 #elif defined(__arm__)
 #define NUTMEM_ALIGNMENT        4

would have been sufficient.

I also remember, that Ole reported similar problems with LPC17xx, but I
can't remember, how he solved that.

Regards,

Harald