No support for Cortex-M0?

[No5]

Hi,

Please can anyone confirm if devkit works with the M0?

I've been wrecking my brain trying to work out why my code keeps jumping to the Hard Fault vector and have realised that its doing it at a MOVW instruction, which is not actually part of the M0 instruction set (its an M3 instruction)....

I'm compiling with "-mcpu=cortex-m0", and don't get any compilation warnings?

Tim

[WinterMute]

In theory devkitARM should be able to target M0 just fine assuming there are no related bugs in upstream gcc and my particular configuration doesn't cause odd side effects on processors that aren't directly tested. You may be better off using the CodeSourcery tools with newer processors - I know they do more testing with a wider range of targets than I do and obviously they have more resources to provide support where needed. Having said that I would obviously like devkitARM to be useful for more than just GBA and DS development so if you're prepared to play around a little and see if we can track down the source of the issue it would be appreciated.

Do you have a small testcase which emits the wrong instructions that we can use for testing purposes? Really I just need a snippet of C code and the compile options so I can see the output.

It's possible that the configuration options I use to allow targetting several arm processors without building libraries for every possible variant are getting in the way. I set things up for a base ARMV4t with multilibs for big endian and thumb2 using --with-march=armv4t --enable-interwork --enable-multilib and some minor tweaks to the gcc configuration files which determine which variants of the libraries get built. That armv4t arch will be used as default when no -march is specified so you may need to use -march=armv6-m and possibly -mthumb too.

There's always a chance that this is a bug in upstream gcc that's causing movw instructions to be emitted in error - we should be able to narrow that down by checking whether the instructions are coming from your code or from the precompiled libraries. From a bit of research it looks like M0 may possibly need it's own multilib options.

[No5]

Hi,

I've made a test case for you.

Its one line of C and it produces instructions that are not part of the M0 set.

To build, just do a "make all" in the root directory.
Hope this helps.

[No5]

If there's anything else I can do to help, please let me know.

Thanks,
Tim

[WinterMute]

Sorry but I think you might be about to kick yourself ...

You're specifying -mcpu=cortex-m3 in this testcase instead of -mcpu=cortex-m0 - code looks fine if you make that change but I don't have any m0 boards to test with.

[No5]

Thankyou - you've spotted the source of my problem.

I'm using Eclipse with a plugin called "GNU ARM Eclipse" which automatically sets include paths and customises the build settings screen for different toolchains (CodeSourcery, Yagarto, devkitPro etc.).

There must be a bug in this plug-in. I've just done some more tests and the devkitPro projects it creates only apply your processor selection to the linker and not to the compiler (it always outputs cortex-m3 no matter what core you select).

Thankyou very much for your help - sorry to have wasted your time. I'll report the bug to the Eclipse plug-in guys.

Cheers,
Tim

[WinterMute]

No worries, it only took a few minutes to find that problem so it's hardly wasted time if it helps to make something better.

[No5]

Its some coincedence but it looks as though there really is also a problem with devkitARM and the M0...

I've attached another test case, this time hopefully compiled for the M0

If you look at address 0x28 in the binary, it is a BLX instruction. Nothing wrong with that, but it's being used with a direct address, rather than indirectly via a register. (At register level, the value of bit[0] in the operand is '0' which generates a hard-fault on the Cortex-M0).

This might be the tip of the iceburg, I haven't checked any other instructions.

[WinterMute]

If you have a look at main.o.lst you'll see the offending instruction is a bl there but the linker changes it to a blx. Parts of libgcc are arm assembly which the linker is then seeing & changing the instruction for interworking which obviously we don't want with this architecture.

I'm going to have to build a multilib for armv6-m to sort that one out I think

[WinterMute]

And that turned out to be a little more complicated than I thought it was going to be but devkitARM release 36 now works as expected with cortex-m0/m1 - at least with this testcase