mbed doesn't work on my Teensy, but works on others...

Status
Not open for further replies.

AbeOwitz

New member
Teensyduino works fine for me on Linux and Windows. I have followed the directions, and the compilers, libraries and loaders work well on all 3 Teensy's I just received. This confirms that my OS/drivers/toolchain is configured properly.

However, developer.mbed.org recently released compiler options to develop for the Teensy. They claim it works, but the simplest blinky light example does not work on any of my 3 Teensy's on any of my 3 Linux machines or 1 windows install...

The code is found here: https://developer.mbed.org/users/yoonghm/code/Teensy_MBED_BLINKY/ and it successfully compiles on the mbed web based compiler.

Once compiled online, the server pushes a file.hex which can be loaded by cli or the gui Teensy loader. Neither the one I compile, nor others compiled by others work on my Teensy, but they DO work on theirs.

What's different between my Teensy3.1 and theirs?

Has the Teensy3.1 firmware/loader changed at all? i.e. so that earlier teensy's may work with mbed libraries, but not newer ones? I just got my Teensy's last week...

Does this work on your Teensy? https://developer.mbed.org/media/uploads/yoonghm/teensy_mbed_blinky_teensy3_1.hex

Thanks...
 
Last edited:
@AbeOwitz,

yes, the hex file you sent runs on my Teensy 3.1 without any problem. It blinks the LED and prints "Hello World" every 400 ms.

I know that you guys double and triple checked it all, but are you sure you are using a Teensy 3.1? Can you tell us how the big chip is labelled? It should be something like "MK..."

Maybe, you can discover the serial number of your Teensy. It will be exposed when you run a sketch compiled with the Arduino IDE with the Teensyduino extensions. Under Windows, you can enter into Device Manager and check the USB properties of the device represented by the Teensy. In Linux, you can use "lsusb -v". You'll se a block of information "iManufacturer", "iProduct" and "iSerial". Please let us know what is printed there.

HMYoung mentions that the bootloader button has changed on newer Teensy 3.1's. Is that correct?
 
Last edited:
It's definitely a Teensy3.1 and mk20dx256... I ordered it directly from PJRC...


Code:
lsusb -v -s 003:002                                                                                 [7:24:38]

Bus 003 Device 002: ID 16c0:0483 Van Ooijen Technische Informatica Teensyduino Serial
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            2 Communications
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x16c0 Van Ooijen Technische Informatica
  idProduct          0x0483 Teensyduino Serial
  bcdDevice            1.00
  iManufacturer           1 Teensyduino
  iProduct                2 USB Serial
  iSerial                 3 1054850
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           67
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x01
          call management
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x06
          sends break
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0010  1x 16 bytes
        bInterval              64
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x03  EP 3 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x84  EP 4 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
  (Bus Powered)

Button Pressed:

Code:
 lsusb -v -s 003:005                                                                                 [7:38:58]

Bus 003 Device 005: ID 16c0:0478 Van Ooijen Technische Informatica Teensy Halfkay Bootloader
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x16c0 Van Ooijen Technische Informatica
  idProduct          0x0478 Teensy Halfkay Bootloader
  bcdDevice            1.03
  iManufacturer           0 
  iProduct                0 
  iSerial                 1 00019C0D
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xc0
      Self Powered
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      22
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              64
Device Status:     0x0000
  (Bus Powered)
 
Last edited:
This issue has been rectified.

We had set the system and flash clock speeds too high 72MHz and 36MHz respectively.
Whilst this worked on many boards, some became unstable or would not run after being flashed.

The system and flash clock speeds will now be 48MHz and 25MHz respectively after the current pull request has been accepted.
(that should be 36MHz and 24MHz)

Other Mbed users have reported this has fixed the problem.

A little disappointing, however I don't think this will impact too much on the overall speed.
Perhaps the recent batch of Freescale MCU's have been made out of recycled beer bottles :)
 
Last edited:
It doesn't entirely explain the difference between older and newer teensy 3.1s, but I thought I remember that some buses (SPI?, I2C?) work at some frequencies but not others. Does 96MHz work?
 
Its all about manufacturing tolerances, quality of silicon etc. I had three boards that worked fine extending the clock limits, then I bought another recently to find it was not at all stable.
This is why the manufactures give specifications that should work 100% of the time.
Intel bench mark all their processors during production, the ones that will go faster sell for more money.

Don't know if 96MHz does actually work, providing the prescalers can be set correctly then perhaps it would. But I would be concerned with stability as we have already experienced.

This does remind me of a few years back overclocking 386 and 486 Intel processors when motherboards began to have more clock setting flexibility, we experienced exactly the same phenomenon.
 
96 MHz works great on Teensy 3.1. Teensyduino uses 96 MHz as the default speed. It's proven to be very stable.

Many people who've tried the higher overclocking options (by editing board.txt) report 120 MHz is also very stable. 144 MHz has been reported to experience rare crashes, even though it seems to work much of the time. These results aren't terribly surprising when you consider Freescale makes many other Kinetis microcontrollers using the exact same 90 nm silicon process, which are specified at 100 and 120 MHz.

Normally we talk of the "system clock", which is the speed of the ARM Cortex-M4 processor, system bus, RAM and DMA engine.

When configuring the chip, there are 3 clocks you must choose, all of which must be integer division of the PLL, which of course you also configure using a multiplier and divider from the 16 MHz crystal. Normally the system clock is the same as the PLL (divide by 1). The other 2 clocks are called the "Bus clock" and "Flash clock", and they normally run slower.

The Bus clock doesn't actually control the speed of the main memory bus. Why Freescale chose that name is a mystery to me. It really controls the speed of most peripherals. Freescale specifies the bus clock at 50 MHz maximum. Teensyduino sets it to 48 MHz when the processor runs at 96 MHz. I've done much less experimenting with overclocking the peripherals, partly because the integer division doesn't allow fine grained control, and partly because 48 MHz gives very good peripheral performance. But every indication points to the bus clock having quite a lot of margin for overclocking.

The Flash clock is the 3rd clock you must configure. Freescale specifies it at 25 MHz max. Teensyduino configures it at 24 MHz. Experimentation has shown the Flash clock has very little extra margin for overclocking. Teensy 3.1 seems to run well with the flash at 28 MHz. 33 MHz almost always crashes! 36 MHz can't possibly work.

24 MHz might seem very slow, but nearly all the flash-based microcontrollers on the market use similar speeds for their flash memory. Flash memory has a fundamental trade-off between speed versus density. Atmel, NXP and ST all uses similar clock divide ratios for their flash. Often this is called "wait states" or other terms, and some of them bury this info deep within the details of their flash memory chapter of their datasheets, probably because they don't want to give the impression their chips are slow. But the inescapable truth is flash memory is always much slower in all these single-chip ARM microcontrollers.

To allow code to run fast, they all use wide buses that feed buffers and small cache memory. Inside Teensy 3.1, the flash memory uses a 64 bit bus. So each flash memory fetch at 24 MHz is reading 8 bytes into the caches or one of several buffers, and the flash cache is designed to speculatively read ahead (assuming no branches) during cache hits. Of course, cache misses do cause the processor to wait, so it's far from perfect. That's why we have the "FASTRUN" keyword, to put speed critical code into the single-cycle RAM.

FWIW, the NAND flash memory chips inside extremely fast solid state disc drives use a similar scheme. An entire row (1 kbyte or more) is read into a RAM buffer inside the chip, with an access time of approx 1 us. You don't seem Samsung or Micron calling their chips 1 MHz. Then accesses within the buffer can be made very quickly. They do love to quote those speeds! The net speed is only fast because the flash has a slow but extremely wide bus into a fast buffer. Fast SSD use many chips in parallel, feeding a large RAM-based cache... all because the actual physical flash memory is fundamentally not very fast. Despite the marketing and specsmanship games, the fundamental nature of flash memory is high cell density and large total memory size comes at a cost of relatively slow access times.

During the nearly 2 years we've made Teensy 3.1, Freescale has shipped 3 different silicon revisions. The markings on the chip have been "1N36B", "2N36B" and "3N36B". I don't know when they released each one. I don't have any inside info from Freescale about the differences. I can tell you, even now, the chips we're receiving are a mix of 2N36B and 3N36B. I haven't rigorously tested each version, and I have only a small number of boards with the oldest 1N36B version. But so far, every indication is all 3 versions work about the same for overclocking. None of them allows the flash memory to run significantly faster.
 
Last edited:
Wow! great information here, thank you for your time Paul.

I did check the chip markings on the devices I have. The 2N36B versions do run at the higher rate and definitely do work with the flash set to 36MHz. I double checked the clock set ups and ran a few tests to be sure. The 3N36B would either not start or only run for a few seconds. Setting the flash to 24MHz resolved the issue and both work with the bus clock at 72MHz. I did not try any temperature range tests though.
We have decided to set the Mbed default clocking to 72MHz core, 36MHz bus and 24MHz flash to ensure reliability over the specified temperature and running conditions. However there are other set ups that can be defined in the system library should a user want to experiment and have success, we can add that as an optional user selectable set up. I think the 96MHz set up would be a good addition.
But I will leave that for others to have some fun :)
 
While it's technically overclocking, you should consider using 96 MHz core, 48 MHz bus and 24 MHz flash. That's Teensyduino's default and it's proven to work very well on all the Teensy 3.1s. The extra speed boost, especially on the bus clock, is also really nice.

That combination will also give you the best compatibility when porting code between the two systems!
 
You've twisted my arm, and it does make sense on the compatibility. Testing now with 96MHz setup same as your Teensyduino. I'm sure it will be fine, but I have to check it running with the Mbed API's first. All going well I will set that as the Mbed default speed. I'll take a look at the higher clock speeds and compare between the two MCU revisions, see if I can get some more definitive data.
 
The 96MHz set up is now done and is the default clock set up. There are two other set ups available IRC and 72MHz should anyone want to use these.
I have checked this on the 2N36B and 3N36B mask chips and all appears to be working as expected.
Whilst the Teensy3.1 is not shown on the platform page, here is the link that should allow it to be added to your platforms:

https://developer.mbed.org/platforms/teensy-3-1/
 
Status
Not open for further replies.
Back
Top