Porting to EFM32

Hi,

I'm on my way to porting Espruino to the EFM32 series of microcontrollers..

I guess I will have more, but right now I have three questions:
1) What is the boardname_af.csv used for? I can't seem to find what files are generated from that file..
2) Right now the target compiles, but the output binary is 0 bytes. Any pointers to what might have happened?
3) Which IDE are you guys usually using when developing the target code? Any pre-made projects for any IDE?

Hi,

Great! It might be worth reading the Build Process Readme if you haven't already.

1) What is the boardname_af.csv used for?

This is for STM32 boards, and you can ignore it (at least initially). It's part of the pin definitions stuff that works out jspininfo.c.

On STM32, to get a certain peripheral to work on a certain pin, you have to set that pin's 'alternate function' register to the right number. The CSV file helps the STM32's board.py file fill in the correct numbers for each peripheral on each pin.

2) Right now the target compiles, but the output binary is 0 bytes. Any pointers to what might have happened?

On other platforms you generally have some assembly code that gets pulled in that contains the real entrypoint. That initialises the stack pointer, sets up memory, etc, and then finally calls main. It's possible you didn't include that? If so, GCC would have just optimised everything out.

I'd focus on trying to get a simple 'hello world' EFM32 project compiling and working with a Makefile and arm-none-eabi-gcc. Once that's done it's probably a lot easier to get the same thing working with the Espruino Makefile, and to then modify your main.c to start to initialise Espruino itself.

3) Which IDE are you guys usually using when developing the target code?

I use Eclipse, and build just by running make (using arm-none-eabi-gcc) on Linux.

I'd do the same if I were you (using your favourite editor) - trying to use some other toolchain you're just making life a lot harder for yourself!

Thanks!

Yup, that's what I'm working on. Just getting a toolchain up running and making main.c blink a LED.

But bargh. I'm doing some headbashing here. Basically the Silicon Labs development tools (Simplicity Studio) is based on Eclipse+GCC so it shouldn't be that hard to get it up running right?

We don't supply these startup-files as objects, only as assembly or C-files, so if the build system is expecting that I understand that they might be causing problem...?

I tried using a pre-defined linker file, and setting the object-file generated from startup_efm32gg.c to a PRECOMPILED_OBJS. Still no luck. Any other suggestions on what might be wrong?

I'm using GNU ARM 4.8_2013q4

The version of GCC you're using sounds fine... It should be pretty easy to get going - you'd hope :)

You shouldn't need object files either... PRECOMPILED_OBJS does point to an object file, but that file is built by the Makefile (I'm afraid I forget how though).

... actually, is it worth you just using mbed to set up a 'hello world' project? You can then export that to GCC and work from there?

Good tip!
Here's the mbed compiled with gcc:

arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb  -c -g -fno-common -fmessage-length=0
-Wall -Wextra -fno-exceptions -ffunction-sections -fdata-sections -fomit-frame-p
ointer -MMD -MP -DNDEBUG -Os -DEFM32GG990F1024 -DTOOLCHAIN_GCC_ARM -DTOOLCHAIN_G
CC -DTARGET_CORTEX_M -DTARGET_Silicon_Labs -DARM_MATH_CM3 -DMBED_BUILD_TIMESTAMP
=1450779582.39 -DTARGET_EFM32 -D__CORTEX_M3 -DTARGET_M3 -DTARGET_EFM32GG_STK3700
 -D__MBED__=1  -std=gnu++98 -fno-rtti -I. -I./mbed -I./mbed/TARGET_EFM32GG_STK37
00 -I./mbed/TARGET_EFM32GG_STK3700/TARGET_S­ilicon_Labs -I./mbed/TARGET_EFM32GG_S
TK3700/TARGET_Silicon_Labs/TARGET_EFM32 -I./mbed/TARGET_EFM32GG_STK3700/TARGET_S­
ilicon_Labs/TARGET_EFM32/TARGET_EFM32GG_­STK3700 -I./mbed/TARGET_EFM32GG_STK3700/
TARGET_Silicon_Labs/TARGET_EFM32/emlib -I./mbed/TARGET_EFM32GG_STK3700/TARGET_S­i
licon_Labs/TARGET_EFM32/emlib/inc -I./mbed/TARGET_EFM32GG_STK3700/TOOLCHAI­N_GCC_
ARM  -o main.o main.cpp
arm-none-eabi-gcc -mcpu=cortex-m3 -mthumb  -Wl,--gc-sections --specs=nano.specs
-u _printf_float -u _scanf_float -Wl,--wrap,main -Wl,-Map=bin/mbed_blinky_low_po
wer.map,--cref -T./mbed/TARGET_EFM32GG_STK3700/TOOLCHAI­N_GCC_ARM/efm32gg.ld -L./
mbed/TARGET_EFM32GG_STK3700/TOOLCHAIN_GC­C_ARM  -o bin/mbed_blinky_low_power.axf
main.o mbed/TARGET_EFM32GG_STK3700/TOOLCHAIN_GC­C_ARM/board.o mbed/TARGET_EFM32GG
_STK3700/TOOLCHAIN_GCC_ARM/cmsis_nvic.o mbed/TARGET_EFM32GG_STK3700/TOOLCHAIN_GC­
C_ARM/mbed_overrides.o mbed/TARGET_EFM32GG_STK3700/TOOLCHAIN_GC­C_ARM/retarget.o
mbed/TARGET_EFM32GG_STK3700/TOOLCHAIN_GC­C_ARM/startup_efm32gg.o mbed/TARGET_EFM3
2GG_STK3700/TOOLCHAIN_GCC_ARM/system_efm­32gg.o -lmbed  -lstdc++ -lsupc++ -lm -lc
 -lgcc -lnosys -lmbed  -lstdc++ -lsupc++ -lm -lc -lgcc -lnosys

Here's the standard compilation using Simplicity Studio:

Building file: C:/SiliconLabs/SimplicityStudio/v3/devel­oper/sdks/efm32/v2/Device/SiliconLabs/EF­M32GG/Source/system_efm32gg.c
 
Invoking: GNU ARM C Compiler
arm-none-eabi-gcc -g -gdwarf-2 -mcpu=cortex-m3 -mthumb '-DDEBUG_EFM_USER=1' '-DEFM32GG990F1024=1' '-DDEBUG=1' -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/EFM32GG_STK37­00/examples/usbdhidkbd" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/EFM32GG_STK37­00/config" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/CMSIS/Include" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/emlib/inc" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/common/bsp" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/common/driver­s" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/Device/SiliconLabs­/EFM32GG/Include" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/usb/inc" -O0 -Wall -c -fmessage-length=0 -mno-sched-prolog -fno-builtin -ffunction-sections -fdata-sections -std=c99 -MMD -MP -MF"CMSIS/efm32gg/system_efm32gg.d" -MT"CMSIS/efm32gg/system_efm32gg.o" -o "CMSIS/efm32gg/system_efm32gg.o" "C:/SiliconLabs/SimplicityStudio/v3/deve­loper/sdks/efm32/v2/Device/SiliconLabs/E­FM32GG/Source/system_efm32gg.c"
Finished building: C:/SiliconLabs/SimplicityStudio/v3/devel­oper/sdks/efm32/v2/Device/SiliconLabs/EF­M32GG/Source/GCC/startup_efm32gg.S
Finished building: C:/SiliconLabs/SimplicityStudio/v3/devel­oper/sdks/efm32/v2/kits/common/drivers/s­egmentlcd.c
Building file: C:/SiliconLabs/SimplicityStudio/v3/devel­oper/sdks/efm32/v2/kits/common/bsp/bsp_t­race.c
 
 
Invoking: GNU ARM C Compiler
arm-none-eabi-gcc -g -gdwarf-2 -mcpu=cortex-m3 -mthumb '-DDEBUG_EFM_USER=1' '-DEFM32GG990F1024=1' '-DDEBUG=1' -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/EFM32GG_STK37­00/examples/usbdhidkbd" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/EFM32GG_STK37­00/config" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/CMSIS/Include" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/emlib/inc" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/common/bsp" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/kits/common/driver­s" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/Device/SiliconLabs­/EFM32GG/Include" -I"C:/SiliconLabs/SimplicityStudio/v3/de­veloper/sdks/efm32/v2/usb/inc" -O0 -Wall -c -fmessage-length=0 -mno-sched-prolog -fno-builtin -ffunction-sections -fdata-sections -std=c99 -MMD -MP -MF"BSP/bsp_trace.d" -MT"BSP/bsp_trace.o" -o "BSP/bsp_trace.o" "C:/SiliconLabs/SimplicityStudio/v3/deve­loper/sdks/efm32/v2/kits/common/bsp/bsp_­trace.c"
Finished building: C:/SiliconLabs/SimplicityStudio/v3/devel­oper/sdks/efm32/v2/Device/SiliconLabs/EF­M32GG/Source/system_efm32gg.c
 
Finished building: C:/SiliconLabs/SimplicityStudio/v3/devel­oper/sdks/efm32/v2/kits/common/bsp/bsp_t­race.c
 
Building target: STK3700_usbdhidkbd.axf
Invoking: GNU ARM C Linker
arm-none-eabi-gcc -g -gdwarf-2 -mcpu=cortex-m3 -mthumb -T "STK3700_usbdhidkbd.ld" -Xlinker --gc-sections -Xlinker -Map="STK3700_usbdhidkbd.map" --specs=nano.specs -o STK3700_usbdhidkbd.axf "./src/descriptors.o" "./src/main.o" "./emusb/em_usbd.o" "./emusb/em_usbdch9.o" "./emusb/em_usbdep.o" "./emusb/em_usbdint.o" "./emusb/em_usbhal.o" "./emusb/em_usbtimer.o" "./emlib/em_assert.o" "./emlib/em_cmu.o" "./emlib/em_ebi.o" "./emlib/em_emu.o" "./emlib/em_gpio.o" "./emlib/em_int.o" "./emlib/em_lcd.o" "./emlib/em_system.o" "./emlib/em_timer.o" "./emlib/em_usart.o" "./Drivers/hidkbd.o" "./Drivers/segmentlcd.o" "./CMSIS/efm32gg/startup_efm32gg.o" "./CMSIS/efm32gg/system_efm32gg.o" "./BSP/bsp_trace.o" -Wl,--start-group -lgcc -lc -lnosys -Wl,--end-group
Finished building target: STK3700_usbdhidkbd.axf
 
Building hex file: STK3700_usbdhidkbd.hex
arm-none-eabi-objcopy -O ihex "STK3700_usbdhidkbd.axf" "STK3700_usbdhidkbd.hex"
 
Building bin file: STK3700_usbdhidkbd.bin
arm-none-eabi-objcopy -O binary "STK3700_usbdhidkbd.axf" "STK3700_usbdhidkbd.bin"

And here's the output from the Espruino building at the moment:

arm-none-eabi-gcc -Wall -Wextra -Wconversion -Werror=implicit-function-declaration -fno-strict-aliasing -Wno-sign-conversion -Wno-conversion -Wno-unused-parameter -std=c99 -Os -fno-common -fno-exceptions -fdata-sections -ffunction-sections -flto -fno-fat-lto-objects -Wl,--allow-multiple-definition --param inline-unit-growth=6 -c -mcpu=cortex-m3 -mthumb -g -gdwarf-2 -DGIT_COMMIT=bdfda3e6cc2fb0083a77aa1fdeb­e77887fcf4821 -DBUILDNUMBER="52" -DEFM32GG990F1024 -DUSE_DEBUGGER -DUSE_MATH -DARM -DLINK_TIME_OPTIMISATION -DEMBEDDED -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targets -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/src -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/gen -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/libs/math -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/cmsis/Include -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targets/efm32 -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/Device/SiliconLabs/EFM32GG/Include -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/emdrv/nvm/inc -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/emdrv/rtcdrv/inc -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/emdrv/common/inc -I/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/emlib/inc gen/jswrapper.c -o gen/jswrapper.o

arm-none-eabi-gcc -Winline -Os -fno-common -fno-exceptions -fdata-sections -ffunction-sections -flto -fno-fat-lto-objects -Wl,--allow-multiple-definition --param inline-unit-growth=6 -mcpu=cortex-m3 -mthumb -g -gdwarf-2 -Wl,--gc-sections -T/c/Users/apsyvert/Documents/work/githu­b/Espruino_SL/Espruino/targetlibs/Gecko_­SDK/Device/SiliconLabs/EFM32GG/Source/GC­C/efm32gg.ld -o espruino_1v84.52_efm32ggstk.elf src/jslex.o src/jsvar.o src/jsvariterator.o src/jsutils.o src/jsnative.o src/jsparse.o src/jspin.o src/jsinteractive.o src/jsdevices.o src/jstimer.o src/jsspi.o gen/jswrapper.o libs/math/acosh.o libs/math/asin.o libs/math/asinh.o libs/math/atan.o libs/math/atanh.o libs/math/cbrt.o libs/math/chbevl.o libs/math/clog.o libs/math/cmplx.o libs/math/const.o libs/math/cosh.o libs/math/drand.o libs/math/exp10.o libs/math/exp2.o libs/math/exp.o libs/math/fabs.o libs/math/floor.o libs/math/isnan.o libs/math/log10.o libs/math/log2.o libs/math/log.o libs/math/mtherr.o libs/math/polevl.o libs/math/pow.o libs/math/powi.o libs/math/round.o libs/math/setprec.o libs/math/sin.o libs/math/sincos.o libs/math/sindg.o libs/math/sinh.o libs/math/sqrt.o libs/math/tan.o libs/math/tandg.o libs/math/tanh.o libs/math/unity.o targets/efm32/main.o targets/efm32/jshardware.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/Device/SiliconLabs/EFM32GG/Source/GCC/­startup_efm32gg.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/Device/SiliconLabs/EFM32GG/Source/syst­em_efm32gg.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emdrv/rtcdrv/src/rtcdriver.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_assert.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_cmu.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_emu.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_gpio.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_msc.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_rtc.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_system.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_timer.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/emlib/src/em_usart.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/gen/jspininfo.o src/jswrap_array.o src/jswrap_arraybuffer.o src/jswrap_date.o src/jswrap_error.o src/jswrap_espruino.o src/jswrap_flash.o src/jswrap_functions.o src/jswrap_interactive.o src/jswrap_io.o src/jswrap_json.o src/jswrap_modules.o src/jswrap_pin.o src/jswrap_number.o src/jswrap_object.o src/jswrap_onewire.o src/jswrap_pipe.o src/jswrap_process.o src/jswrap_serial.o src/jswrap_spi_i2c.o src/jswrap_stream.o src/jswrap_string.o src/jswrap_waveform.o libs/math/jswrap_math.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/Device/SiliconLabs/EFM32GG/Source/GCC/­startup_efm32gg.o /c/Users/apsyvert/Documents/work/github/­Espruino_SL/Espruino/targetlibs/Gecko_SD­K/Device/SiliconLabs/EFM32GG/Source/syst­em_efm32gg.o
arm-none-eabi-objcopy -O binary espruino_1v84.52_efm32ggstk.elf espruino_1v84.52_efm32ggstk.bin
bash scripts/check_size.sh espruino_1v84.52_efm32ggstk.bin
PASS - size of 0 is under 1016957 bytes
arm-none-eabi-objcopy -O ihex espruino_1v84.52_efm32ggstk.elf espruino_1v84.52_efm32ggstk.hex

I'm totally lost in terms of GCC at the moment. Posting this in a desparate hope that someone might be able to spot the errors...

You could get rid of -Wl,--gc-sections, which might lead to a nonzero file size - it probably still won't work but you might be able to look at the .lst file and get an idea why the entrypoint isn't getting called?

Also can you compile with RELEASE=1 PICO_1V3=1 make and see if that works?

It looks like you're still using Windows as well?

If I were you I'd really just install a VM and use Ubuntu with arm-none-eabi-gcc. Trying to change to do the build under windows as well as porting to a new chip is just asking for trouble.

There are also some webpages on building for EFM32 with Makefiles too - maybe try one of them... Don't use Espruino at all at the moment but just try and get something building with GCC and a Makefile.

Hi,

Thanks for the suggestion. RELEASE=1 PICO_1V3=1 make works fine. Yields a file of 304480 bytes.

Building for the EFM32 with a makefile also works fine, the mbed output above comes from doing just that. Also, the Gecko SDK comes with all examples created for ARM GCC, and they're all building fine.

We have two dev-environments here. Me (the Windows n00b) and Mikael running make in Dokker on a Mac. Both have the same problems. I was just hoping that there would be some GCC wiz here that would immediately spot my mistake, but I guess I'll just have to start at the beginning, removing files and options from the building till it starts working :)

I'd start looking at the Linker file. The binary should at the very least have a Vector table of 100 bytes or so right at the start of it.

However, the linker should throw an error if it can't find the vector table, so I'd assume that for whatever reason the linker file isn't requesting it, or it has been found but is 0 bytes long.

Woah!

It's working. Basically the whole setup was correct including the linker file for the EFM32, but I hadn't guarded the generation of the linker file $(LINKER_FILE): scripts/build_linker.py, so it would overwrite it. Took me a bit to figure that out. We should maybe add a more generic guard around that for other targets that wants to use their own linker file.

Then, ran into the problem of ALWAYS_INLINE, but setting DEBUG=1 solved it (by skipping the attribute).

Right now it's compiling and running, but currently when including the jsvInit(); in main.c, causes the compiler to exit with undefined reference to `_sbrk' and undefined reference to `_etext'. Probably no biggie, so will see how it goes.

Great! The Linker file thing sounds like a pain - perhaps it could only generate it if the path was in the gen directory?

For the _sbrk and _etext, I'd have though that would only happen if code used malloc - which it shouldn't. Perhaps you could look in gen/platform_config.h and see if JS_VAR_CACHE_SIZE is set (it should be) - you definitely shouldn't have RESIZABLE_JSVARS as that is what is used when running under something like Linux.

Actually, some code in Espruino checks where the stack is vs the end of memory, so it tries not to overflow the stack by recursing too far. It could be that you just need to define those variables in the linker file at the right place. In fact I think build_platform_config actually lets you change the name of them (or some of them) if you don't want to change the linker file: https://github.com/espruino/Espruino/blo­b/master/scripts/build_platform_config.p­y#L161

For _sbrk, often what I do in these cases is define the symbol in a C file, compile it, and the search the assembly code for _sbrk in order to see what is using it (it might be something got pulled in that shouldn't be)

Hi,

You guys probably know this already, but I'm just posting the update for further reference if anyone else runs into the same problem. The Undefined reference to `_etext' is because _etext is being used directly from jswrap_process.c here: extern int LINKER_ETEXT_VAR; // end of flash text (binary) section. This define is located in platform_config.h produced by build_platform_config.py.

The reason for the mismatch is that the EFM32 linker (and startup-file) defines this variable as __etext (notice two underscores). So after updating the build_platform_config.py to use this name instead for the LINKER_ETEXT_VAR it's all good.

The other undefined references to _sbrk and _exit was solved by adding -Wl,--start-group -lgcc -lc -lnosys -Wl,--end-group to the linker options for the EFM32.

Where is this set (jsiStatus & JSIS_ALLOW_DEEP_SLEEP)?

I've finished implementing the deep sleep functionality so it sleeps for real if waiting for things that take more than 1/2 second but I have to comment out the above line. Of course then the console does not work very well :)

I can't see the above flag being set for jsiStatus anywhere? Guessing that it should only be set when a console is not connected?

Also, on another note, if I want to use 115200 baud for the console, how do I do it (on the PC side)?

Where is this set (jsiStatus & JSIS_ALLOW_DEEP_SLEEP)?

The setDeepSleep(true) function. It's great that you implemented deep sleep - and it wakes up properly on pin change events and if setTimeout/etc is used?

Generally it doesn't sleep if USB is connected (but I think the EFM32 doesn't have USB?) - and yes, since the clocks stop the Serial UART usually dies, and that makes the console almost unusable :) You can hack something up using some JS code and RTS and CTS if they exist though :)

There's a branch where I'm looking at adding software serial - I'm hopeful that (at least for low baud rates) that may be usable from deep sleep.

if I want to use 115200 baud for the console, how do I do it (on the PC side)?

In the Web IDE? It's under 'settings' and 'communications'.

On the Espruino itself you can do Serial1.setup(115200) which should work, but potentially you may have to re-specify the pins too: Serial1.setup(115200, {rx: ..., tx:...})

Thanks for the info!

It wakes properly to tell me the time every 10 seconds, so I guess so..? Pin wake-up is not yet implemented.. I'm also having a bit of trouble testing the utility timer and Delay() functions. Do you have some simple test-cases for the framework?

The EFM32 have USB, but it's not implemented yet :) Actually that touches another comment. If a device has USB, USB is usually defined. I would consider moving the define for the VCP to a more descriptive define, as some devices in the future will have USB but chose not to implement it.

I actually had to change the part-number of the EFM32 to one without USB to make it compile.

Ahh - I think if the part has USB but USB isn't used, we should make sure it doesn't get defined. Do the EFM32 headers define it then?

For the timers, the best thing might be to include the software PWM support (copy it from the top part of AnalogOutput in STM32) and to enable soft PWM on a pin. Hopefully you'll be able to see quite easily if you're scheduling the timers correctly.

Also digitalPulse (the jshardware implementation probably wants copying too - ideally it needs taking out to a shared file) - that's a good way to test as it should schedule a one-shot timer for a fixed time period.

Yes, The EFM32 headers define USBand I think most parts that have USB-capabilities will define that...

K, thanks I will try. Right now I'm struggling to get the setWatch to work correctly (without sleepdeep first). I can send a pull request and you can see if there are some obvious mistakes.

Yup. Got it working. Just USB and analog left and we're good :)