It is working. See https://developer.mbed.org/users/yoonghm/code/Teensy_MBED_BLINKY/

I had also commented on https://developer.mbed.org/platforms/teensy-3-1/

Thank you Paul!

It's not working for me...

All 3 of my PJRC-sourced Teensy 3.1's work with the blink_fast_teensy31.hex files from PJRC, but the above Teensy_MBED_BLINKY->*.hex doesn't work at all for me. (Nor am I getting a TTY in /dev.)

Platformio's compilation doesn't work either...

Any suggestions?

~/Desktop/ teensy-loader-cli -mmcu=mk20dx256 -w -s -v Teensy_MBED_BLINKY_TEENSY3_1.hex
Teensy Loader, Command Line, Version 2.0
Read "Teensy_MBED_BLINKY_TEENSY3_1.hex": 24748 bytes, 9.4% usage
Error opening USB device: Resource temporarily unavailable
Waiting for Teensy device...
 (hint: press the reset button)
Found HalfKay Bootloader
Read "Teensy_MBED_BLINKY_TEENSY3_1.hex": 24748 bytes, 9.4% usage
Programming.........................
Booting

Did you import the example from https://developer.mbed.org/users/yoonghm/code/Teensy_MBED_BLINKY/

You have to use teensy.exe hex loader from https://www.pjrc.com/teensy/loader.html

For offline compilation, i use the gcc toolchain for ARM that comes with Arduino. I export test program and modify from there.

HM Yoong,

I did import that example.

I'm on Linux. The Linux Teensy CLI and GUI loaders work fine with teensyduino compiled binaries. So, my environment is confirmed working.

So the mbed web IDE will not compile native Teensy3.1 .hex binaries?

Hi:

If you import the example above and compile it, it will give you a hex file. Just use Teensy CLI (Linux) or Teensy.exe (Windows) to download the file. It works.

Still no luck... I imported the example. I compiled it. Downloaded it and programmed it...

What do you get for md5sum?

Same thing happend to me when I accidentally used a Teensy 3.0 instead of a 3.1. Visually they're hard to distinguish (you have to look at the chip labelling).

You can also use the GUI loader (teensy[.exe]) and specify the file through the menu. Worked for me.

My next step was to add a USB serial port, using the USB_Serial library. Worked as well.

Binary/hex output from Teensyduino works regardless of loader.

Binary/hex output from mbed env does not work.

Therefore, there is something wrong with the code/binary from mbed.

Update: Does not work on Windows either... However, example teensyduino blinky app work fine... Again, toolchain appears to work. Same md5sum for binary generated in mbed on windows env.

Hi AbeOwitz:

Here is the hex file from mbed.org using the example from https://developer.mbed.org/users/yoonghm/code/Teensy_MBED_BLINKY/

/media/uploads/yoonghm/teensy_mbed_blinky_teensy3_1.hex

If it still cannot work, do try on a) Using another Teensy 3.1 board on the same computer b) Using another Teensy 3.1 board on other computer

Unfortunately, it does not work for me, on any of my machines (3 of them), nor from Linux nor Windows. Nor with any of my 3 Teeny's. The Teensy's work fine with Teensyduino example code, and with my own code driving a color LCD via SPI, and accessing SD cards. So, I know they work...

All I can think of is my Teensy may have different firmware, since I just got mine last week.

I have started a thread on PJRC's forum and have included the hex file in the post.

Note that your binary has a different MD5 sum than mine. Why would the same source generate different binaries for you vs me?

Here is the screenshot. Can you compare with yours?

Update: I tried on a new teensy 3.1 (the program button has changed), I could not flash too - same problem as yours. The bootloader is not open source.

I have successfully loaded several Mbed programs using the Teensy loader version 1.15 and the latest 1.21, both work. My Teensy3.1 dates back to December 2014, perhaps the new versions have changed in some way. This is a bit strange, we are still loading a .hex file the start of flash surely Arduino does the same? In what way has the program button changed?

I have the same blinky revision as in the screenshot.

My new Teensy's also have the white button.

Glad you saw the same problem with the new Teensy's. I lost a few hours to retracing and verifying my installation/tool chain...

I also used offline GCC_ARM (that comes with Arduino ) to compile the Blinky program but i still have the same problem.

I also replaced the linker script in mbed with the one from teensyduino - still has the same issue.

I examined the temporarily files (header files, object, compile options), generated by Arduino after its compiling, but did ot anythng special.

I am wondering what is there so special that the bootloader refuses hex from mbed toolchain. Does it check for certain function that is only available in Arduino.

One thing i would like to share that a) Binary using Arduino library is 3 times smaller than binary using mbed libraries. b) GCC_ARM produces smaller size binary than the online toolchain.

I'm not sure that we can conclude that it's a bootloader problem. Maybe, something's going wrong in the startup code.

I don't know if MBED comes with a fault handler, but it might be an idea to implement a very simple handler that just blinks the LED and outputs a register dump in case of a hard fault or bus fault.

Sorry, I don't have sufficient experience on how to do this in mbed. However, I have derived a fault handler for the Arduino platform based on Paul Stoffregen's example code in mk20dx128.c and attached it to this message: /media/uploads/jbliesener/faulthandler.c . Maybe Paul Staron can try to include it in the Teensy port and see what happens on newer Teensys....

In an Arduino environment (I use ArduinoEclipse), it is sufficient to just include this file into the project. The name of the function is linked to the weakly defined symbol fault_isr. This handler initializes Teensy's UART0 (on pins 0 and 1 - PTB16 and PTB17) and prints out the stack frame. As the fault can be imprecise, the indicated pc might be a few instructions after the faulty one. Line 70 in the code is an adjustment for the stack frame and might(!) depend on the compiler version and settings, don't know. I'm sure this can be done better...

Don't know if it helps...

I have ordered another Teensy3.1 from CPC (Farnell) today, I will check which button that has fitted, may be old stock though so might get the previous version. They have over 50 in stock at time of writing (£20.39 inc VAT and delivery at the moment, UK).

http://cpc.farnell.com/teensy/teensy3-1/microcontroller-arduino-compatible/dp/SC13539?mckv=sTq8thwgJ_dc|pcrid|61927053617|kword|teensy3.1|match|e|plid|&CMP=KNC-GUK-CPC-GEN-SKU-MCU

The picture does show the black 'program' button, again may be an old picture.

Perhaps these others are 'clone' devices that Paul Stoffregen warned me of.

The Mbed compiler sets the execution address to the start of Flash. I believe it runs up using the IRC clock to dump the NVIC parameters into RAM and then jumps to the user program code where the system set up runs clock source settings, etc. then into the main program code.

Most MCU Flash resident bootloaders use the start of Flash to initialise the bootloader code that sits somewhere at the top of the Flash and the user code load and start address is offset further up the Flash, usually to 0x400.

From what I understand when the 'prog' button is pressed the on Teensy3.1 the bootloader MCU dumps the bootloader code into the RAM of the K20 MCU, that way no Flash is used for the process. It then runs this code to load the user code to the Flash. Clearly this was at the start of Flash. Perhaps the new versions are set differently. It can only be bootloader on the interface MCU that may have changed in some way.

I do not use Arduino, is the program execution address the same? if so why would that work and not with the Mbed code?

If we get stuck here, I will see if we can offset the Mbed scatter file definitions and use the MCU's own bootloader function and revert back to USB drag and drop programming, but that would eat up a small amount of Flash for the bootloader code.

That may be a better option but does detract from the original design of the this board and if Arduino programming is used it would wipe out the bootloader that would need re loading before using it on Mbed again.

FYI

HM Yoong's code works perfectly fine on my Teensy.

bcg@bcg-laptop:~/projects/teensy-mbed/Teensy_MBED_BLINKY$ teensy_loader_cli --mcu=mk20dx256 -w -v Teensy_MBED_BLINKY_TEENSY3_1.hex 
Teensy Loader, Command Line, Version 2.0
Read "Teensy_MBED_BLINKY_TEENSY3_1.hex": 24748 bytes, 9.4% usage
Waiting for Teensy device...
 (hint: press the reset button)
Found HalfKay Bootloader
Read "Teensy_MBED_BLINKY_TEENSY3_1.hex": 24748 bytes, 9.4% usage
Programming.........................
Booting

Mine has the black button and is from somewhere around Dec 2014 to Jan 2015.

Very excited about mbed on teensy3 btw, will be glad to help troubleshoot if necessary.

Tried with a fresh Teensy 3.1 from PJRC (received Aug 2015; has green solder mask and white button). Blinky program will upload via cli and teensy loader GUI on Ubuntu 14.04LTS, but does not execute. lsusb reveals that the teensy is not recognized once flashed with HM Yoong's blinky code. After reflashing with the slow blink example in the teensy_loader_cli root directory the device shows up (it has different product IDs depending on whether it's running the bootloader or not; 0486 normally, 0478 when running the halfkay bootloader). I have an older teensy 3.1 that I can test as well. I'd really like to see mbed working with teensy 3.1 and will help however I can to make that happen.

So does anyone have a clue what changed except the color of the button? And if I am correct, old 'Arduino' hex files for the Teensy do work on both, but the mbed hex files only work on the old one?

I'd be surprised if it would be due to a (slightly) different MCU on the board. So that brings it either to the loader programs (on purpose) screwing up the hex files, or what I would guess is most likely, a new version of the bootloader doing some kind of 'check' on the hex file and rejecting ours. But since his bootloader is closed source and we have no debug capabilities whatsoever that is going to be a tough one to crack, only the designer of it might know the reason for it.

Btw when you say the teensy is not recognized, you mean the USB drive? That is working as intended: The Arduino code automatically starts a USB serial apparantly, on mbed this is not built-in. If you want that you need to include the USBDevice library and make a USBSerial object. However a bit pointless if it isn't booting in the first place :).

Something else to try would be making a bare minimum blinky project on codewarrior or another compiler (so no mbed), and trying the hex file created by that.

I did get another Teensy3.1, 'black button' though so I can't check further.

There is a quick check that can be done.

Here is a pre-built bootloader for the Teensy3.1 that I have tried and works with the 'black button' teensy3.1

/media/uploads/star297/utaskerserialboot_teensy3-1_srec_kboot_hid_msd.hex

Use the Teensy Loader to program the Teensy3.1

When loaded and rebooted a MSD drive will appear in windows explorer named 'UPLOAD_DISK' and the led will flash.

You can then drag and drop .BIN code files the same as usual MBED function.

This file came from and more details here:

http://www.utasker.com/kinetis/TEENSY_3.1.html

This could be an option to use this and revert to .BIN files providing we can offset the compiler user program flash load and start point to 0x8080. The start of Flash is used for the bootloader function.

If someone with the 'white button' version could check this please and if it works, perhaps we could use this.

I think the only way to reliably way to distiguish "old" from "new" would be solder mask. Before Jan 22, 2015, the solder mask was black. After, it's green. Yes, my pre-1/22 board has a black button, and my post has a white button, but that may be purely coincidental. On both my pre-1/22/15 board and my post 1/22/15, I can flash with an mbed compiled .hex file, but the teensy doesn't boot. There is a USBSerial instance in the blinky sample code, but nothing shows up in lsusb.

The bootloader Paul linked to shows some promise. As advertised, a storage device shows us as "UPLOAD_DISK" on the file system, led flashes at 4 or 5 Hz, and I can drag a .bin file (compiled from blinky sample code with gcc toolchain using mbed supplied makefile) to the device. Before flashing with .bin, lsusb shows a "Freescale Semiconductor, Inc." device with VID:PID of 15a2:0073. After flash, the device restarts and the LED is on, but the LED doesn't flash. Nothing in listed in lsusb.

Just to make sure I'm on the same sheet of music, I'm using sample code from here (linked prevously in this thread):

https://developer.mbed.org/users/yoonghm/code/Teensy_MBED_BLINKY/

Edit: to clarify, I tried Paul's bootloader on both the pre and post 1/22 boards.

Just tried a few things out on my two boards, the old one works solidly. However the new one is temperamental, resets and starts 3 out of 5 times and will freeze after a few minutes.

I have set the clock set up to '0' in the system_MK20DX256.c file (MBED-SRC), 32KHz IRC mode.

This is now stable, clearly no USB.

clock set up '2' also works but timers are fast.

You may want to try yours with only led 'blinky' no USB.

I believe we may have the Flash clock speed too high, looking into that now.

I tried blinky with no USB. No luck; same behavior as before on both old and new. I will try modifying the clock set up and see what that gets me. Ultimately I'd need USB, but one bite of the elephant at a time.

Don't worry too much for the moment, we have checked and changed the clock set up code and pegged back the Buss, Flash and RAM speed. My board is working properly now including USB device, but need to check everything else to be sure.

In the meantime if you want to try yourself, replace line 191 with this in the system_MK20DX256.c file

Remember to change back to clock set up '3'

 SIM->CLKDIV1 = SIM_CLKDIV1_OUTDIV2(1) | SIM_CLKDIV1_OUTDIV4(2);

Just as point: While I don't have a better explanation, I am not as certain as Paul that this is it :P. So if you could check with a different clock setup that would be really appreciated. While this needs to be changed anyway, it would be nice knowing if we need to continue the search for the problem with the new boards or not.

I noticed this post - which might help explain the different behavior between boards:

https://forum.pjrc.com/threads/28726-new-teensy-3-1-not-recognised-by-windows?p=73952&viewfull=1#post73952

There was a change in January 2014 on what default code was loaded into the Teensy affecting how it would show up: previously as a USB serial device, afterwards as RawHID.

The button change is more recent but seems to be a carry-over from the new Teensy-LC and just a mechanical improvement.

It means the hardware was unchanged. The USB was probably done already for all boards we currently have, but for sure should not affect how it programs the Teensy. That makes the frequency problem a reasonable explanation: It could simply be that new batch is produced in a slow corner, where we are setting it too far out of spec to function properly.

I have carried out quite a few checks now but will run some 24 hour tests. Changing back to the original set up reproduces the problems immediately. We just need to know if this fixes other users problems or not.

It comes down to production tolerances, we just had some good ones that could be 'stretched' a bit further.