Noob question about ARM microcontrollers

[VinnyCordeiro]

I'm thinking about making the move to ARM microcontrollers. I've been working with Atmel mcu's since 2007 and I'm fairly familiar with them (but in no way I'm an expert, far from that): Arduino, ICSP programming, USB programming using FLIP, I've tried them all successfully.

But AVR architecture is showing its limitations for some ideas I have. Problem is that I know little about ARM. I know that GCC can compile code for it, but how I flash the mcu itself? (And many other questions that I don't want to bother you with.)

If someone can link me some easy to understand resources for learning, I would appreciate. I'm intending to use Freescale MK20DX128VLF5, an ARM Cortex-M4 (the same used on Infinity keyboard).

[VinnyCordeiro]

Well, my Google-fu already showed me an easy and simple answer: https://github.com/kiibohd/controller/wiki/Bootloader

I'll let the post here for future questions.

[flabbergast]

Just a word of warning - the chip you mention comes blank, no bootloader, no nothing. So to flash the kiibohd bootloader, you'll need to use some kind of SWD debugger - I used bus pirate with the scripts from mchck project. After that you can of course use dfu-util over usb without any external circuitry.

[Findecanor]

That chip is was on the Teensy 3.0 with bootloader.
Edit: PJRC does not sell the Teensy 3.0 any more, in favour of the Teensy 3.1 which has a MK20DX256, and the Teensy LC which has a MKL26Z64VFT4.

PJRC sells bare ATmega32U4's with their bootloader already installed for you to put into your own projects, but they don't do it for the ARM/Freescale chips unfortunately.

[VinnyCordeiro]

Just a word of warning - the chip you mention comes blank, no bootloader, no nothing. So to flash the kiibohd bootloader, you'll need to use some kind of SWD debugger - I used bus pirate with the scripts from mchck project. After that you can of course use dfu-util over usb without any external circuitry.

Yeah, I saw that. I already had to deal with AVR microcontrollers without factory bootloaders (PIC and old ATmega), no big deal. I wish there was something like USBtinyISP for ARM mcu's, though.

That chip is was on the Teensy 3.0 with bootloader.
Edit: PJRC does not sell the Teensy 3.0 any more, in favour of the Teensy 3.1 which has a MK20DX256, and the Teensy LC which has a MKL26Z64VFT4.

PJRC sells bare ATmega32U4's with their bootloader already installed for you to put into your own projects, but they don't do it for the ARM/Freescale chips unfortunately.

Thank you for the update. My biggest problem with Teensy is that it isn't an open source initiative. I respect Paul's position but do not agree with it. I know that everything else on Teensy is open source, but the bootloader isn't and, for my purposes, that's unacceptable.

[flabbergast]

The point with Teensy 3.0/3.1/LC is that there's another chip apart from MK20DX* that serves as a "bootloader", i.e. it takes over when flashing firmware and writes it to MK20DX*. The MK20DX* is "blank", i.e. without any bootloader. You can buy those chips from Paul, but it's real expensive (like $8/chip or something) - EDIT: this is precisely the closed part of the teensy 3.* line. The MK20DX* itself is "completely open"

[flabbergast]

Yeah, I saw that. I already had to deal with AVR microcontrollers without factory bootloaders (PIC and old ATmega), no big deal. I wish there was something like USBtinyISP for ARM mcu's, though.

Well, it's the usual chicken/egg problem.

If you want I can send you a bootloaded mchck usb stick, I have one extra I don't need (you pay postage from UK, it should be something like £3 from UK). I think the mchck project has a "SWD debugger" firmware that you can use to flash another MK20DX* - but you might want to check the mchck github first to make sure, it's been a while since I've done this.

[VinnyCordeiro]

Yeah, I saw that. I already had to deal with AVR microcontrollers without factory bootloaders (PIC and old ATmega), no big deal. I wish there was something like USBtinyISP for ARM mcu's, though.

Well, it's the usual chicken/egg problem.

If you want I can send you a bootloaded mchck usb stick, I have one extra I don't need (you pay postage from UK, it should be something like £3 from UK). I think the mchck project has a "SWD debugger" firmware that you can use to flash another MK20DX* - but you might want to check the mchck github first to make sure, it's been a while since I've done this.

Looking here at MCHCK site, it is indeed possible to use one as a debug adapter. The guy even posted a flashing rig he made for it! https://mchck.org/blog/2013-09-12-mc_hck_flashing_rig/

Send me your PayPal email to me by PM, this thing will be useful. And thank you.

[twiddle]

Just as a note, if you intend to continue doing further development with ARM I would strongly recommend using an external SWD debugger. I'm not entirely sure that the MCHCK firmware will allow debugging of an external target - last time I looked it was just being used for programming, ie cloning itself to another chip.

 Some development boards allow their debug hardware to be used to program/debug external controllers, for eg the Kinetis FRDM series and the ST Nucleo boards, but they tend to be restricted to only work with debugging a specific group of chips. You can use OpenOCD with the Bus Pirate for a cheap, but community-supported alternative that will work across a variety of manufacturers, but I think hands down the winner is the J-link EDU (about $50-60 US). It supports pretty much every major Arm micro in existence, and lets you use any GDB implementation to perform both flashing and source-level debugging. I'm using one which you can see in my controller experiments thread, and even as a hobbyist I think it's probably the best money I've spent on a development tool to date.

Also, for learning the Kinetis line I'd suggest checking the "MCU on Eclipse" blog here , and taking a look at Kinetis Design Studio.

[flabbergast]

I agree with twiddle on this - it tends to be quite a headache to get various "cheaper" solutions to work well in general; each has their own set of little catches. Even openOCD+bus pirate took me a while to set up properly. On the other hand - you probably learn a lot what does which part of the setup do, but it does take time.

BTW, I thought that mchck can actually do debugging of other mchcks - I haven't tried myself though. For me the setup is not very transparent, it is based on a bunch of ruby scripts (I guess it depends on the level of expertise, mine is quite low).