Add Xadow M0 as target device about gcc4mbed HOT 18 CLOSED

Hello Mikaël,

I have looked at your .mk file and it appears to contain what I would expect to see. I don't see any obvious errors.

Are you able to build code with the online compiler for this target and have it run successfully? What about exporting for GCC_ARM from the online compiler? Does that work?

from gcc4mbed.

Hi, I'm able to compile an upload from the online compiler.

But I can't export anything useful, all option are grayed out (except: zip, online IDE and emblocks (don't work)) looks broken to me...

I tested zip once, but could not get it to compile.

from gcc4mbed.

Ok, that gives me a couple of things to check on then. I will look into it more later this evening.

from gcc4mbed.

Thank you, Please tell if I can help (run a/some test binaries).

from gcc4mbed.

One other clarification, it is failing on a basic sample like HelloWorld right? I see one bug in the GCC_ARM startup asm code where it uses the completely wrong names for the external interrupt handlers but that typically would only matter if your code was expecting to catch such an interrupt by naming a handler something like: FLEX_INT0_IRQHandler. Typically the mbed SDK doesn't use the external interrupt vectors from FLASH anyway as it copies them to RAM and sets them up correctly there.

from gcc4mbed.

I've only tried HelloWorld.

from gcc4mbed.

Ok, I just looked at the online compiler and definitely see one problem that might cause the issue that you are seeing. You could try building this C program on your development machine and then use it to update the LPC interrupt vector checksum:

#include <errno.h>
#include <stdint.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
    FILE*       pFile = NULL;
    const char* pFilename = NULL;
    uint32_t    checksum = 0;
    uint32_t    vectors[7];
    size_t      byteCount;
    int         seekResult;
    size_t      i;

    /* Check command line parameters to make sure that user provided needed image filename parameter. */
    if (argc < 2)
    {
        fprintf(stderr, "Usage: lpc_checksum app.bin\n"
                        "Where: app.bin is the filename of the image .bin file to be checksummed.\n");
        return 1;
    }
    pFilename = argv[1];

    /* Open the image .bin file. */
    pFile = fopen(pFilename, "r+");
    if (!pFile)
    {
        fprintf(stderr, "Failed to open %s (%s).\n", pFilename, strerror(errno));
        return 1;
    }

    /* Read in the first 7 entries from the image's vector table. */
    byteCount = fread(vectors, 1, sizeof(vectors), pFile);
    if (byteCount != sizeof(vectors))
    {
        fprintf(stderr, "%s wasn't big enough to be a valid image file.\n", pFilename);
        fclose(pFile);
        return 1;
    }

    /* Calculate the vector checksum for the first 7 entries. */
    for (i = 0 ; i < sizeof(vectors) / sizeof(vectors[0]) ; i++)
    {
        checksum += vectors[i];
    }
    checksum = -checksum;

    /* Write the checksum out into the 8th vector entry. */
    printf("checksum = 0x%08X\n", checksum);
    seekResult = fseek(pFile, 7 * sizeof(uint32_t), SEEK_SET);
    if (seekResult)
    {
        fprintf(stderr, "Failed to update checksum in %s (%s).\n", pFilename, strerror(errno));
        fclose(pFile);
        return 1;
    }
    byteCount = fwrite(&checksum, 1, sizeof(checksum), pFile);
    if (byteCount != sizeof(checksum))
    {
        fprintf(stderr, "Failed to update checksum in %s (%s).\n", pFilename, strerror(errno));
        fclose(pFile);
        return 1;
    }
    fclose(pFile);
    return 0;
}

from gcc4mbed.

WOW, I'm still trying to wrap my head around that, but it seems to work very well (at least for helloword).
Thank you very much.

from gcc4mbed.

I am happy to hear that it gets HelloWorld working.

Most of the NXP LPC parts need that checksum but most of the mbed enabled devices have code in their firmware update path which automatically update it.

from gcc4mbed.

And, with explanations, Thanks again.
I assume that my problem is solve and I won't matter what the size or complexity of my binary as long as I 'checksum' it.

from gcc4mbed.

I assume that my problem is solve and I won't matter what the size or complexity of my binary as long as I 'checksum' it.

Yes, that should be the case.

from gcc4mbed.

Hello, I'm back with another problem, I can't do floating point operation with the offline compiler.

The "Analogin-HelloWorld" example work as intended when compiled online but fail to compute/output any float when compiled offline.

I've tried adding -mfloat-abi=soft to C_FLAGS without success.

from gcc4mbed.

I guess I don't know what your definition of doesn't work is but if it is just that you don't get the right output from something like printf() then you should check your project's makefile and make sure that
NO_FLOAT_PRINTF isn't set to a non-zero value. If you copied the makefile from HelloWorld then it would be linking in a smaller version of printf() which doesn't support the display of floats. There is a similar flag for scanf() floating point support.

from gcc4mbed.

And you are right, thank you.

from gcc4mbed.

Two things:

• If you are happy with XADOW_M0 support now, then please feel free to send me a pull request with your new XADOW_M0-device.mk file and I will roll out in the next gcc4mbed update.
• There might be a way to get the checksum automatically updated during the build process so that you don't need to build the lpc_checksum app that I provided the code for above. However it wouldn't be simple and I would probably only do it if it was a major inconvenience for several users. If people do want such a change then feel free to reopen this issue and add your feedback below :)

from gcc4mbed.

I am very happy with XADOW_M0 support, but I miss the time and the
knowledge (non-git user) to do that.

I think the checksum could be calculated/injected from a bash script, I may
take a look a that later.

In the mean time should I send you the file ?

On Sat, Jun 6, 2015 at 9:15 AM, Adam Green [email protected] wrote:

Closed #28 #28.

—
Reply to this email directly or view it on GitHub
#28 (comment).

from gcc4mbed.

@adamgreen I just ran into this same issue trying to add gcc_arm export to mbed sdk for the Xadow M0 board. Your lpc_checksum just saved me hours of poking at code to find the problem. Thank You!

There's partial support for the XADOW_M0 target in the sdk, but only the emblocks cmsis target was included (hence the greyed out export options in the online editor). I added the missing targets, and for gcc_arm it's an almost direct copy of the LPC11U35_501 target, including the LPC11U35.ld script.

If you don't mind helping me pinpoint the bugs that tweak the LPC interrupt vector checksum, I'm more than happy to create a new device makefile for the Xadow M0.

from gcc4mbed.

I just reread the thread and noticed the "it wouldn't be simple and I would probably only do it if it was a major inconvenience", so I'm going to take a guess that adding an extra lpc_checksum step the makefile would be the prudent path to pursue.

from gcc4mbed.