Great progress! Old and new flash with no issue (.hex via teensy_loader_cli). Program behavior on both is a little odd. Blink works fine without USBSerial. With USBSerial, device reports as busy with LED blinking. After 30 seconds or so, the LED stops blinking. I can then start a terminal connection to the serial device and the LED starts blinking again. As soon as the terminal is closed, the LED stops blinking. But both devices are obviously flashing, booting, and running the code now.

Can you run this program:

https://developer.mbed.org/teams/CommunityContributors/code/USBSerial-RTC-HelloWorld/

If you don't have the 32KHz crystal fitted the RTC will show but wont advance, otherwise it will work. I'm using this now, when I close the terminal the led blinks briefly, when terminal running it blinks for a brighter longer period. Doesn't stop for me though. I'm using windows 7, there could be USB handshaking differences.

Paul, the clock tweaks definitely seem to have resolved my issues. So far so good.

Tried the RTC example. I don't have a 32.2KHz crystal installed. I get nothing. No device enumerated in lsusb, no serial device, and no LED.

Disregard. It's working now. I thought the clock setting had been changed in mbed-src in the linked code; I didn't check. My apologies.

So, results are similar to the basic USBSerial/Blink. LED pulses and device reports busy for 30 secs or so after reboot. LED then is continually on, and I can start a serial connection. Serial output is as expected and LED starts to blink again. Ending the serial connection, the LED is continually on.

I can repeat the connect/disconnect as many times as I like. With the serial terminal open, the LED pulses away happily. I've left it running for just a few minutes, but I think it would continue to pulse away indefinitely without complaint as long as the serial connection is open.

Testing on Ubuntu 14.04 LTS.

Tried a simple HID implementation, stripping down the extant HID sample code. Freezes at call to hid.send();

#include "mbed.h"
#include "USBHID.h"
 
//We declare a USBHID device. By default input and output reports are 64 bytes long
USBHID hid; 
 
//This report will contain data to be sent
HID_REPORT send_report;
 
DigitalOut led(LED1);
 
int main(void) {
    send_report.length = 64;
    led = 1;
    while (1) {       
        //Fill the report
        for (int i = 0; i < send_report.length; i++)
            send_report.data[i] = rand() & 0xff;
 
        //Send the report
        hid.send(&send_report);

        led = !led;
        wait(0.5);
    }
}

Didn't work on mine, then realised I pasted your code into the wrong folder, tried in the modified SRC folder and it works, left it running for 30 minutes.

Can you try on a Windows PC?

I can try on a Windows machine on Monday. I did try the HID example on OS X. Blinks away happily. I can try and get something cobbled together to verify received packets, but I have no reason to think it's not working. The same chip freezes at the call to hid.send() when plugged into Ubuntu (LED continually on).

Were you able to verify packets received on Windows?

I'll put togther a Fedora live DVD and see test as well.

Huh. dmesg told the following story on Ubuntu:

[79800.692944] usb 3-2: new full-speed USB device number 73 using xhci_hcd
[79800.822693] usb 3-2: New USB device found, idVendor=1234, idProduct=0006
[79800.822701] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[79800.822705] usb 3-2: Product: HID DEVICE
[79800.822709] usb 3-2: Manufacturer: mbed.org
[79800.822712] usb 3-2: SerialNumber: 0123456789
[79800.824609] hid-generic 0003:1234:0006.01A0: hiddev0,hidraw2: USB HID v1.11 Device [mbed.org HID DEVICE] on usb-0000:00:14.0-2/input0

Light on solid - no flash. There were two devices in /dev/usb - hiddev0 and hiddev1. On a whim, I tried reading from both, i.e.

sudo cat /dev/usb/hiddev1

hiddev1 immediately spit packets and the light started flashing happily. Killed the cat process and led1 kept flashing. So something's up with how Ubuntu's handling the device when it's first plugged in, but I don't know precisely what that something is.

I'll try fedora tomorrow and see how it works.

This problem is a bit tricky but we have a lot of people willing to spend time to work on it. It is great.

Did you try on new and old teensy 3.1 boards?

I changed the call to hid.send() to be non-blocking (hid.sendNB()). It blinks merrily now, babbling gibberish over HID.

I'm still on the hunt for what's going on with the blocking call and the kernel when the device is initially plugged in.

I tried testing on a black masked teensy after getting the HID example working a green masked board. The .hex files downloaded from the online compiler now won't flash. Both teensy_loader_cli and the teensy GUI are reporting parse errors (HEX parse error, line 2). Tried a reboot and two different browsers. Anyone else having issues now?

Edit: To clarify, issue is with the downloaded hex file and has nothing to do with which board version is attached.

Has anyone tried other peripherals - I2C, SPI, or UART? I can test I2C and UART over the course of the next few days.

Code compiled offline (GCC) flashes just fine. .hex files downloaded from the online compiler still won't flash. Odd.

HM Yoong - both versions of the Teensy (black solder mask (w/ black button) and green solder mask (w/ white button)) work just fine with Paul's revised clock settings. Thanks, Paul!

Did some more testing with HID. I adapted a simple libusb based client on the host to connect with the Teensy. If I use hid.send(), the code will block (LED not flashing) if the OS doesn't have active handles reading the device. hid.sendNB() flashes away happily when there's no connection. Sounds like it may be working as intended?

I have sent a PR for the clock set up changes and tested pretty much everything.

Proof bellow, Serial Oled display, SPI SD card (to store station pre-sets) and I2c RDS FM radio chip.

Thanks Paul. It also meants that the speed of the board will have to be reduced.

Update: Saw the commit from Paul

This is where some of the confusion sets in, terminology, exactly which speed is reduced? As we have proved clock speeds can be exceeded however at a cost of stability. Some may work but not others. I had a batch of three boards that all worked at the faster clock rates, totally stable. Then we saw others having problems.

So the standard Mbed settings are now as follows:

CPU core clock remains as per data sheet specification 72MHz.

Bus clock spec is now set to 36MHz. Previously 72MHz.

Flash clock speed is now set to 24MHz. Previously 36MHz.

You can certainly tweak the settings to experiment with 'how fast can my board go', but due to manufacturing tolerances there is no guarantee that another MCU will operate with your faster settings. If you have boards that do work at higher clock rates as I have then you can use the faster original settings. Apparently these will operate reliably at 96MHz, if anyone wants to pursue this and get it working, it can replace one of the 'useless' clock set ups in the library.

The practical, functional tests I carried did not show any noticeable differences in performance speed.

Testing 96MHz setup (48MHz bus). Its running on both silicon mask revisions, 2N36B and 3N36B, the 2N36B MCU revision is capable of faster flash clock rates. If you look on the MCU you will see either of these numbers, the newer MCU production (3N36B) is the version I have that was unstable on our original over clocked settings.

If the tests pass running at 96MHz we will set this as the default speed, however there will be the 72MHz setup defined as well just in case. The 96MHz setup apparently is standard use with Arduino so in theory its should be stable.

I have sent a pull request with the final clock setups. If Martin is happy with this, the following will apply:

Default Teensy3.1 setup '1' is 96MHz with 48MHz bus and 24MHz flash. This mirrors the default Arduino setup that most users are running with. I have tested all the peripheral functions with MCU temperatures up to 150 degrees centigrade on both MCU mask versions.

Clock setup '0' remains the same using slow internal 32KHz clock source with no USB support, not sure if the USB fractional prescaler can trim this to work. However I don't imagine many will want to this mode in any case, but its there if a requirement for a crystal less system is wanted.

Clock setup '2' in now the Manufacture standard setup at 72MHz, 36MHz bus and 24MHz flash. Not sure if anyone would want this but its there more for a standardisation purpose.

Set up now merged on Mbed-SRC rev. 633

Hiya!

I'm new to all this (just started today, actually), so do bear that in mind when rolling your eyes up at what I'm doing or asking! :-)

I'm trying to get an mbed blink program (you know the one :-) to work on my Teensy 3.1, and the latest thing I tried was:

- exporting Magic Commit 633 to a zip as GCC-ARM/Teensy

(that's https://developer.mbed.org/users/mbed_official/code/mbed-src/export )

(which includes commit 634)

- copying over the blink main.cpp to the mbed-src dir

- adding a couple of bits to the makefile for 'main' and typing 'make'

- uploading the .hex via the Teensy Loader.

But it still doesn't go. :-(

It does seem odd that I have to do that adding-main thing, so any tips would be very much appreciated!

Arduino blink works fine on the board, so the basics are there.

Any ideas?

Duncan Cragg

PS: In fact, I think I'd maybe like a yotta target for the Teensy, although I'm more comfortable with 'make' than anything like that, (or than with online IDEs.. :-). So any idea when a Teensy target will hit the yotta repo?

I don't know if GCC-ARM was ever fixed for the Teensy (not just a Teensy issue, als the K20D50M had problems with it, but since I don't use GCC-ARM myself I have never looked into it).

To be fair, since it is absolutely clear that mbed couldn't possibly, even if they tried, care less about the community, and it really looks like Teensy is never going to be added to the platform list, my interest in fixing stuff is declining anyway.

However for your problem, I would first make sure it works from the online compiler. In general it is also easier to export a simple blinky from online compiler, then you don't have to worry where main.cpp is located and setting anything correct: That should be correct by default (but see top of this post, I don't know if there are (still) GCC-ARM issues). For the online compiler, the platform link is still hidden (which is the reason for my rant above), but here it is so you can add it: https://developer.mbed.org/platforms/Teensy-3-1/

Well I don't know what went wrong before, but it's now actually working! The Teensy loader is a bit random and flaky I guess. I rebuilt, pulled the USB, restarted the loader, set it to manual and off it went this time! :-) :-)

So I still have the two questions:

- is sticking a main.cpp into the downloaded mbed-src really how it's done? :-/

- Teensy yotta target? :-)

Oh, I have a dark-green-painted, white-button Teensy, if that helps! :-)

Cheers! Duncan

Don't make me sad when I've just started my mbed journey! :-)

Well the online compiler isn't up to date with today's 633 fix, so that won't actually work!

When do they update to latest? I quickly diff'd part of an export from there with HEAD and it seems to be very different.

Yes, I found that out myself, and finally found that link - and the blue button over there on the right - myself! It's probably hidden because it's simply not working yet?

Cheers Duncan

Well the Teensy3.1 addition was originally intended for Mbed use, the exporter part was not really my concern. If others want to expand on this they can. AFAIK Keil and GCC export has been added and does work. Since todays SRC update, the important clock set ups have now been merged. These give the user 3 clock set ups, IRC, 72MHz and 96MHz(default). The other consideration was for the silicon mask version of the MCU that had an impact on clock speeds. This has now been corrected and works on the three masks that have been produced (or at least the last two that I have been able to obtain and test).

I have also built a Teensy3.1 equivalent project board (below) without the interface MCU and tested the low power consumption that achieves 6uA in deep sleep (including using a separate low iQ 3.3v regulator). This is programmed using a Segger Flasher with the Mbed generated .HEX file. Tricky to modify the Tennsy3.1 to get access to the SWD connection, but could be done and programed from the interface MCU.

We are only waiting for it to be added to the platform page.

A lot of boards are added to mbed platform list recently. iI think those company has to pay loyalty to mbed. It is fair as it is a buainess The designer of Teensy, AFAIK, never pushes his platform into mbed.

Then they should make this clear and tell it is never going to happen.

Paul - awesome work with the project board! Do you have a schematic you're willing to share? Looks like the supporting cast of passives are hiding on the other side of the schmartboard in the photo. Is that a coin cell for the RTC in the lower left (by the SWD header)?

Nick, it's based on the same schematic on the original Teensy3.1. That is only bare minimum passives (decoupling capacitors) have been fitted underneath and no interface chip. But that's all the Teensy3.1 really is. Yes I fit a small li-ion RTC back up cell that has a 33k resistor and low leakage diode connected to the 3.3v supply to keep it charged when running. The only advantage here is I can run these at very low power using deep sleep and Erik's WakeUp code. The Teensy3.1 will only achieve around 12mA due to the interface chip and it uses the built in MCU 3.3v regulator that seems not to be very efficient. Also I have access to all the digital I/O pins if I need. So unless you need low power and more pins, the Teensy3.1 is a better option to use.

The only problem is programming it. The Segger Flasher Portable is expensive unless it gets a lot of use but is really good and will program ALL the current ARM core MCU's.

Is the 96mhz not the default yet? I just built a test for teensy 3.1 and printed SystemCoreClock 72000000 . how do i get 96mhz

Tom, you need to import and replace the MBED libraries with MBED-SRC:

https://developer.mbed.org/users/mbed_official/code/mbed-src/

The official MBED libraries do not have these changes merged yet, that will happen on the next MBED update.