Bare Metal Programming on Teensy-LC

Status
Not open for further replies.

swheater

New member
Hi, I am hoping to learn about the low level details of the ARM Cortex-M0+ by doing some bare metal programming on the Teensy-LC, but I am finding to hard to get started.

Initially I tried to get started by porting a sample bare metal program for the Teensy-3.1 (https://github.com/dwelch67/teensy_samples), to the Teensy-LC, but without success.

Are there any other starting points more suitable for the Teensy-LC? or documentation on where the loader places the downloaded program, and how control is passed to that program?
Am I right in thinking that the loader doesn't place the program at 0x0000000 and use the standard reset mechanism?

Thanks,
Stuart
 
Arduino is Baremetal :) There is no operating-system.
IF you want to access registers directly, the best is a) to download,&read the reference-manual, b) to look at the Teensyduino-sources.
 
Hi,
Am I right in thinking that the loader doesn't place the program at 0x0000000 and use the standard reset mechanism?
No, the program is placed at 0x0000000. The Loader does not need any space in the Cortex-M0+, because it's in the second mcu on the board.
 
Hi, I am hoping to learn about the low level details of the ARM Cortex-M0+ by doing some bare metal programming on the Teensy-LC, but I am finding to hard to get started.

Initially I tried to get started by porting a sample bare metal program for the Teensy-3.1 (https://github.com/dwelch67/teensy_samples), to the Teensy-LC, but without success.

Are there any other starting points more suitable for the Teensy-LC? or documentation on where the loader places the downloaded program, and how control is passed to that program?
Am I right in thinking that the loader doesn't place the program at 0x0000000 and use the standard reset mechanism?

Thanks,
Stuart
Truly bare metal... forgo all the great work in libraries and apps to adapt?
For ARM Cortex M4? M0?

I suggest that Teensy might not be the best way to go. You'd probably be better with a board that supports hardware debugging with hardware breakpoints, etc. Today, this means SWD (two pins on the ARM MCU).
There are lots of such boards out there, Freescale and ST are, IMO, the best, and I lean toward the latter. The debug "pod" hardware has come down to $20 or so with SWD. Not like ye ole $500 JTAG pod (J-Link, et al).

I'm one that started with ARM7, bare metal for projects several years ago. Certainly not needed or commonly done these days. Especially with all the effort that has gone on by people like PJRC/Paul, and the MCU vendors' libraries.
 
Last edited:
Thank you for the information, and advice.

I will check the changes a I have made against https://github.com/PaulStoffregen/cores, given that the loader behaviour on the Teensy-LC sounds similar to the Teensy-3.1, if I can get the LED to flash, that would be good basis for exploration. I have learned a lot exploring the problem.

At some point I was planning write code to drive the SWD protocol, but that was a future task. I will look at "pod hardware" as it would allow me to make faster progress.

Given this is a learning exercise for me, starting with a blank sheet is appealing, and seeing if any programming techniques from Android, JEE, AngularJS, Node.js, .... lead me any where interesting.

Thanks again for you help,
Stuart
 
Re: Code for SWD (single wire debug)...
The two SWD pins on the Teensy are hardwired to the mini54 chip for bootloading.
And, the SWD protocol per se is in the silicon of the ARM core.

I don't know about Freescale, but ST's SWD pod is $20. Maybe it'll work with the K20 too. Of course, the real joy of SWD comes from the PC software integrated with the GUI, as is done by OCD, IAR, Keil, etc.
 
starting with a blank sheet is appealing

Teensy-LC and Teensy 3.1 are designed to give you very close to a "blank sheet". Your .HEX file is written to the entire flash, starting at address 0. There's no other code in the flash memory. You code starts running by a hardware reset, where the KL02 chip pulses the RESET pin low after your .HEX file is fully written. You code starts up running pretty much with a "blank slate".

Likewise, at hardware power-up, the KL02 (or Mini54 on Teensy 3.x) does not take control. Your code gets to start up the same as if you'd programmed a blank chip and soldered it to a PCB without any programming hardware.

Of course, the Arduino environment is far from a "blank slate". The default build process compiles many files, called the "core library" and links all that with your program. You could consider the core library as a bare metal program... admittedly a rather large one with tons of functionality just waiting to be used. There's even a sample makefile, so you can compile it without running Arduino. Within Arduino, look in hardware/teensy/avr/cores/teensy3 for all that stuff.

Perhaps you can use the core library, and whittle away stuff you don't need? It's already very well tested code, which can probably help you a lot more than the time you'll need to delete the (many) areas you don't need.
 
By cross checking the Teensy-LC port of sample bare metal program (https://github.com/dwelch67/teensy_samples) against "hardware/teensy/avr/cores/teensy3" code and MKL26Z64 reference-manual, I realized that the MKL26Z64 does not have the Watch Dog Timer which that is disabled in the original Teensy-3.1 version.

After that change I was able to flash the LED on the Teensy-LC.

Thank you for you help,
Stuart
 
Status
Not open for further replies.
Back
Top