Add Xadow M0 as target device
RealZogzog opened this issue · 18 comments
Hi, I'm new to mbed, and really wish to compile offline, so first, thank you for your work.
I'm using a quite obscure device: "Xadow M0" based on the LPC11U35FHI33/501 and I'm begging for help to add this device as build target.
It is supported by the mbed SDK so I followed the instructions about 'how to add a device' but with no success.
Here are some infos that may help you help me.
$workspace_tools/build.py -m XADOW_M0 -t GCC_ARM -v
/home/mikael/bin/adamgreen-gcc4mbed-ddb84b1/gcc-arm-none-eabi/bin/gcc-arm-none-eabi/bin/arm-none-eabi-g++ -std=gnu++98 -fno-rtti -c
-Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
-fmessage-length=0 -fno-exceptions -fno-builtin -ffunction-sections -fdata-sections -MMD -fno-delete-null-pointer-checks -fomit-frame-pointer
-mcpu=cortex-m0 -mthumb -O2
-DTARGET_XADOW_M0 -DTARGET_M0 -DTARGET_CORTEX_M -DTARGET_NXP -DTARGET_LPC11UXX -DTARGET_MCU_LPC11U35_501 -DTOOLCHAIN_GCC_ARM -DTOOLCHAIN_GCC -D__CORTEX_M0 -DARM_MATH_CM0 -DMBED_BUILD_TIMESTAMP=1429280269.75 -D__MBED__=1
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/libraries/mbed/common
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/TARGET_XADOW_M0
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/TARGET_XADOW_M0/TOOLCHAIN_GCC_ARM
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/TARGET_XADOW_M0/TARGET_NXP
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/TARGET_XADOW_M0/TARGET_NXP/TARGET_LPC11UXX
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/TARGET_XADOW_M0/TARGET_NXP/TARGET_LPC11UXX/TARGET_MCU_LPC11U35_501
-I/home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/TARGET_XADOW_M0/TARGET_NXP/TARGET_LPC11UXX/TARGET_MCU_LPC11U35_501/TARGET_XADOW_M0
-o /home/mikael/projects/XadowM0/mbed_libs/mbed-master/build/mbed/.temp/TARGET_XADOW_M0/TOOLCHAIN_GCC_ARM/./CallChain.o /home/mikael/projects/XadowM0/mbed_libs/mbed-master/libraries/mbed/common/CallChain.cpp
I used LPC11U24-device.mk as a base for my XADOW_M0-device.mk witch containt:
# Copyright 2015 Adam Green (http://mbed.org/users/AdamGreen/)
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
# Vendor/device for which the library should be built.
MBED_DEVICE := XADOW_M0
MBED_TARGET := NPX_LPC11UXX
MBED_CLEAN := $(MBED_DEVICE)-MBED-clean
# Compiler flags which are specifc to this device.
TARGETS_FOR_DEVICE := TARGET_XADOW_M0 TARGET_M0 TARGET_NXP TARGET_LPC11UXX TARGET_MCU_LPC11U35_501 TARGET_CORTEX_M
GCC_DEFINES := $(patsubst %,-D%,$(TARGETS_FOR_DEVICE))
GCC_DEFINES += -D__CORTEX_M0 -DARM_MATH_CM0 -D__MBED__=1
C_FLAGS := -mcpu=cortex-m0 -mthumb -mthumb-interwork
ASM_FLAGS := -mcpu=cortex-m0 -mthumb
LD_FLAGS := -mcpu=cortex-m0 -mthumb
# Extra platform specific object files to link into file binary.
DEVICE_OBJECTS :=
# Version of MRI library to use for this device.
DEVICE_MRI_LIB :=
# Linker script to be used. Indicates what code should be placed where in memory.
LSCRIPT=$(GCC4MBED_DIR)/external/mbed/libraries/mbed/targets/cmsis/TARGET_NXP/TARGET_LPC11UXX/TOOLCHAIN_GCC_ARM/TARGET_LPC11U35_501/LPC11U35.ld
include $(GCC4MBED_DIR)/build/device-common.mk
Now, it will compile for this target but once uploaded, the board keep booting in 'usb drive mode', so I guess I made something wrong, If someone could point me to what and where...I'll be eternally grateful.
Thanks again,
Mikaël.
P.S. I've tried the mbed forum but I get an error when I try to post !?!
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?
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.
Ok, that gives me a couple of things to check on then. I will look into it more later this evening.
Thank you, Please tell if I can help (run a/some test binaries).
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.
I've only tried HelloWorld.
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;
}
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.
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.
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.
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.
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.
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.
And you are right, thank you.
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 :)
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 notifications@github.com wrote:
—
Reply to this email directly or view it on GitHub
#28 (comment).
@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.
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.