Trying to get uTasker to work with my Teensy 3.6 board

[creitzel]

Hello,

I'm trying to get uTasker to work with my Teensy 3.6 board, and I'm having difficulty. 

As a first step on my project, I'm attempting to get uTasker set up as a USB mass storage device, reading from the SD card on the teensy.

I think I've modified the uTasker app files correctly, I basically turned off everything USB, except for the USE_USB_MSD flag.  I've also got the SDCARD_SUPPORT flag turned on.  Aside from those changes, I haven't changed much in the uTasker app code.

I've been able to build uTasker in gcc, and produce a .hex file that I can load onto the teensy.  I've also been able to get uTasker and the simulator up and running in Visual Studio 2012 Express. 

I run the app in the simulator, and when I attempt to enumerate the usb devices, if I put breakpoints in the USB driver, it stops, and it appears to be returning reasonable values for the descriptors.  It appears to be working there, from everything I can tell.

Now for the problem.  When I load the hex image onto the teensy and reboot it, the first thing I noticed was that the teensy's led lights up, and stays lit.  I didn't expect this, and thought it was odd, but I proceeded.  Next No matter how many times I unload USB drivers, and plug/unplug the teensy, windows doesn't recognize it as a USB MSD device, in fact it doesn't seem to recognize it as a USB anything, until I hit the button on the teensy, and the teensy halfkay loader takes over, at which point Windows recognizes it as an HID device as usual.

I have no clue what I could be doing wrong.  Is there a uTasker example that shows configuring it as a MSD using the SDCard, that I could maybe download, and compare to my settings?  Or, does anyone have any tips on things to check etc?

Any assistance would be greatly appreciated.

Thanks,

Chris

[mark]

Chris

For Teensy3.6 the defines required are
TEENSY_3_6
USB_INTERFACE + USE_USB_MSD
SDCARD_SUPPORT

For gcc make sure that the makefile has its compiler flags set to
C_FLAGS = -mcpu=cortex-m4 -mthumb -mlittle-endian -mthumb -Wall -Wstrict-prototypes -fmessage-length=0 -fsigned-char  -ffunction-sections -fdata-sections
and uses the linker script file
K_1M_256.ld

When you load the hex file the LED MUST blink at 2.5Hz. If it doesn't, it is NOT working yet.

I would recommend starting without neither USB nor SD Card to ensure that in its simplest case the LED flashes, and then add options once you know that it is running.

Regards

Mark

[creitzel]

Hi Mark,

Thanks for the reply.

I've gone through the project, and verified everything that you posted is correct. 

Basically the initial version of uTasker that I downloaded from the links in the email was already pretty much configured with the settings above, for the teensy 3.6.  I only had to switch the linker script if I remember right. 

I also disabled the SD Card support by commenting out the #define SDCARD_SUPPORT line in config.h.  And I disabled the USB support by adding #define DEVICE_WITHOUT_USB to config.h.  This all builds fine, but when I load it onto the teensy, I still get a solid LED, no flashing what-so-ever.  On the image on the simulator, the LED does in fact blink on and off, so I figure it has to be some kind of teensy specific setting somewhere that I'm missing.  Any ideas on what could be wrong? 

Anyways, until I hear back from you, I'm going to go spelunking in the code, and see if I can find where you are toggling the LED, and see if I can see something in there that is hanging up or something.

Thanks,

Chris

[mark]

Chris

Beware that the GCC build generates several hex files (for standalone operation, operation with a boot loader and a combined loader/application).
Ensure that you load "uTaskerV1.4.hex" and not one of the others.

Note that I have never use the Teensy 3.6 but have set up for it and simulated, plus it has been used by someone who confirmed that it operates. At the moment I don't see a cause for it not running since it is set up to run from the 16MHz crystal, which means that it is essentially the same as NXP K65 and K66 references. To make it completely clock independent one can set RUN_FROM_HIRC so that it runs directly from its internal 48MHz clock so that it should be 100% HW-independent.

Attached are four hex files that I just generated (one simple case without USB and SD card, and one with USB-MSD from SD card - built with the open source V1.4.11 and the developer's V1.4.12 code bases) to see whether one operates on your HW.

Regards

Mark

[creitzel]

Mark,

Thanks for the input. 

I am aware of the 3 separate hex files that gcc generates, and I am using the correct one.

I will give the 48MHz clock a try tonight, when I get home from work, and see if I can get it to come to life with that option.

I will also have to give that hex file a try and see if that works. 

One thing though, I only see one hex file attached, does that mean that the 4 separate hex images are combined into that one somehow, and If so, what do I need to do to separate them?  If not, did something get left out of your attachments?

Thanks again,

Chris

[mark]

Chris
I thought that I had attached 4 but it looks like three of them were lost.
Ill try to attach the three missing ones again.
Regards
Mark

[creitzel]

...
Attached are four hex files that I just generated (one simple case without USB and SD card, and one with USB-MSD from SD card - built with the open source V1.4.11 and the developer's V1.4.12 code bases) to see whether one operates on your HW.
...

Ok, so here's the results of my preliminary testing with your 4 hex images. 

Image 1 (uTaskerV1.4.11_TEENSY3_6_Basic.hex):

This loads on to the teensy fine, but it doesn't appear to be doing anything.  The LED never lights up, and no USB devices are recognized by my PC.  I assume this is because you have USB turned off in this build.

Image 2 (uTaskerV1.4.11_TEENSY3_6_USB-MSD.hex):

I get the same results with this image as # 1.  The LED never lights, and no USB devices are recognized by my pc.  The USB response here is the same as what I'm getting with my build.  i.e. the pc never beeps to tell me it has found a new device, and as far as I can tell from using Windows Message Analyzer, the computer isn't even attempting to enumerate the device.

Image 3 (uTaskerV1.4.12_TEENSY3_6_Blinky.hex):

This loads onto the teensy fine, and the LED blinks at what I'm guessing is 2.5Hz (roughly 2 and a half times a second).  No USB devices are recognized by the pc.  I'm again assuming this is because you have the USB disabled in this build.

Image 4 (uTaskerV1.4.12_TEENSY3_6_USB-MSD.hex):

This loads onto the teensy fine, and I get the same LED behavior as Image 3.  The pc recognizes that it's a USB device, and attempts to connect to it, but then gives an error saying that the device is unrecognized.  I am going to test this image a bit more, using Windows Message Analyzer, and see if I can get any data as to why it isn't recognized by the pc.

So to sum up, it appears that there is something different between the 1.4.11, and 1.4.12 versions of uTasker, that causes the 1.4.12 version to run on teensy, and the 1.4.11 version not to.

I will post more results later, if I can get any more data by using Message Analyzer.

Thanks a ton for all of your help on this.  :-)

Chris

[creitzel]

I will post more results later, if I can get any more data by using Message Analyzer.

Ok, so testing with Message Analyzer, it appears that when Windows is enumerating the device, it returns a proper endpoint descriptor for the control endpoint, but then when windows attempts to retrieve a device descriptor, the device is returning all zeros for the fields.  I think this is what is causing windows to report the device as unrecognizable.  If this was what your build was coded to do, I would say the 1.4.12 version is working correctly.  If not, I'm not sure what is going on with it, because I can't see the code you built it with  :-)

[mark]

Chris

I did some tests on a FRDM-K66F board and found that the Open Source version is missing various settings for K66 operation, which explains why V1.4.11 didn't run on the Teensy 3.6. The RAM memory location was, for example, not correct which resulted in a hard fault as soon as variables were used.

Since there were a number of changes required I did the following:
1. I moved the Open Source project to GITHUB - see http://www.utasker.com/forum/index.php?topic=1721.msg7086#msg7086 for links
2. I made a development branch with various changes that allowed me to run the project on the FRDM-K66F (blinky and USB-MSD) however I couldn't test FS USB as the Teensy 3.6 uses (on its main USB connector) since the FRDM-K66F has only HS USB available. The test was therefore mainly to verify that the code essentially runs (resp. doesn't crash).
3. In the development branch I inherited a couple of things from the professional version in the process:
- BLINKY define in config.h which allows just an LED to be blinked to simply configure an absolute minimal project
- micro-second TICK resolution support
- K66 and FRD-K66F support
- Various driver upgrades that should be unnoticeable generally but were needed for compatibility

Therefore I recommend checking out the development branch from GIT hub and verifing that it is basically operational on the Teensy 3.6.
I didn't notice anything that would cause USB issues but this can be looked into further once the version is essentially operational on that board.

Good luck

Regards

Mark

[creitzel]

Mark,

Ok, I've done what you recommended.  I am now running the dev version with your changes in it.  I am now able to successfully reproduce the same results that I got with your 1.4.12 hex files, here, by building the project myself, using gcc.

Blinky comes up, and flashes the LED as expected, and if I just define USB_MSD and SDCARD_SUPPORT, I can reproduce your hex file that had MSD and SDCARD support.  Unfortunately, Windows still throws the Unrecognized device error. 

Initially, I also was trying to turn on USB_HS_INTERFACE as well, as I want to try and get the fastest USB rate that I can, due to my project transferring mp3 files.  When I did this, the code seemed to run on the teensy, but the LED blink pattern was weird.  By that, I mean that it seemed to only blink once every second or so, and it didn't appear to be a constant interval between (As I was counting seconds, sometimes it would be slightly less than a second before it blinked again, and sometimes it would be slightly longer).  Not sure if that is expected or not, but I've disabled USB_HS_INTERFACE for now, so that I can attempt to debug the USB enumeration problem.

Oh, and one other question for you.  When I run either of these builds in the simulator, it is reporting a 120kHz clock rate at the top of the screen.  I know the 3.6 supports a 180kHz clock rate, and I was wondering if there is a define somewhere that controls that, or if uTasker maxes out at 120kHz. 

Thanks again for all the assistance on this,

Chris

[creitzel]

Mark,

I think I found a typo in the new codebase.  In the file usb_cdc_descriptors.h, at line 1112, you currently have:

    (OUT_ENDPOINT | USB_MSB_OUT_ENDPOINT_NUMBER),                       

I believe this should be:

    (OUT_ENDPOINT | USB_MSD_OUT_ENDPOINT_NUMBER),                       

I just discovered it, as I was trying to turn on the USB_CDC support, so I can try and dump some state info out through the serial port. 

I've not yet worked with your USB serial stuff yet, but I need to get familiar with it anyways, as I'm sure I'm going to need some way of debugging my code, when I get to the point of trying to write my backside interface to the Pi.

Anyway, I figured you'd want to know :-)

[creitzel]

Mark,

I am having no luck debugging the USB thing from the windows side.  Windows Message Analyzer just shows windows requesting a device descriptor 4 times, and getting back a descriptor with all zero values.  I figured I would attempt a few other USB device types thru uTasker, and it doesn't appear to matter which USB device I turn on, they all behave the same in windows.

So far I've tried

USE_USB_CDC
USE_USB_MSD
USE_USB_HID_RAW
USE_USB_HID_MOUSE
and USE_USB_HID_KEYBOARD

I did encounter another compile error in the process of trying USE_USB_HID_KEYBOARD:

Code: [Select]

../usb_application.c: In function 'control_callback':
../usb_application.c:2785:47: error: 'USB_KEYBOARD_INTERFACE_NUMBER' undeclared (first use in this function)
                         if (iHID_Interface == USB_KEYBOARD_INTERFACE_NUMBER) { // keyboard interface number
                                               ^

it appears that USB_KEYBOARD_INTERFACE_NUMBER is in fact a valid identifier, at least for some compiler define configurations.  Maybe I'm just missing another define that I should be turning on?

I have poked around quite a bit in the code, but I've not yet been able to determine where the device descriptor is actually being sent back to the host, so I can't really see if there is something that appears incorrect there.

[mark]

Chris

I believe that the zeroes seen are due to the FS USB not having rights to access Flash. The descriptors are const values in code and so the enumeration uses them directly, but if the controller doesn't have Flash access privilege I have seen that the values tend to be 0, or possibly random.

When I checked I can confirm that the K66 FS USB (not tested since the NXP boards tend to want to 'show off' the HS USB instead) had its FS USB crossbar master set to 3 (which is the typical value) but it actually needs it set to 4 (because the Ethernet controller takes over master 3). I have checked in a new kinetis.h version in the "development" branch with a change labeled {95} which now gives the K65 and K66 their own crossbar master ordering which should correct this issue (again I don't have any board to test FS USB on the K66 - they always have HS, but I am 95% confident since it is not the first time that I saw this behavior).

This is the new block, as reference:

    #if defined KINETIS_K65 || defined KINETIS_K66                       // {95}
        #define FMC_FPAPR_ETHERNET              FMC_PFAPR_M3AP_RD        // Ethernet is bus master 3
        #define FMC_FPAPR_USB_FS                FMC_PFAPR_M4AP_RD        // USB FS is bus master 4
        #define FMC_FPAPR_SDHC                  FMC_PFAPR_M5AP_RD        // SDHC is bus master 5
        #define FMC_FPAPR_USB_HS                FMC_PFAPR_M6AP_RD        // USB HS is bus master 6
        #define CROSSBAR_MASTER_ETHERNET        MASTER_M3
        #define CROSSBAR_MASTER_USB_FS          MASTER_M4
        #define CROSSBAR_MASTER_SDHC            MASTER_M5
        #define CROSSBAR_MASTER_USB_HS          MASTER_M6


I have also updated usb_keyboard_descriptors.h since it was missing the define for USB_KEYBOARD_INTERFACE_NUMBER, which is 0 in the non-composite case.

Good luck

Regards

Mark

[creitzel]

Mark,

I will definitely test the new code when I get home tonight, after work.  For my project, I am actually more interested in the USB HS interface, rather than the FS interface, as I would like to take advantage of the faster transfer speeds if I can.  But, when I tried turning on the HS compiler define, I got that weird LED behavior, so I wasn't sure if it was working correctly or not.  I figured I'd just turn that off for now, and try to resolve some of the other issues first.  At some point, I am going to want to switch back to that mode, and get it working though.

All of that said, if I can help with your testing of the FS stuff, I'm more than willing.  Just let me know what you want to do.  I'm relatively new to all of this (embedded micros, and usb stuff), but I'm willing to help you run whatever tests you want, using my teensy :-)

I'll post results of my latest testing later tonight  :-)

[mark]

Chris

The K66 has a new PLL dedicated to generating a 480MHz USB PHY clock, which however needs the VBUS to be connected to work.

Since I haven't used it in a real product yet I have presently accepted that the PLL will not work unless the HS USB is connected to a host. In fact, the 'final' and 'complete' solution would probable be to make USB initialisation conditional on the VBUS being present and wait if it isn't. If the cable is disconnected it also needs to be detected and abort operation because the PLL freezes and so the USB blocks if not handed completely.

The Open Source code does have the HS PHY initialisation but it WILL hang if the VBUS is not connected since the PLL will not start (forever loop).

I just checked in the latest HS driver too since there was a bug fix in it for something unrelated (only noticeable in specific situation).

If you can verify its operation (with VBUS connected) on the Teensy 3.6 it would be good and then you could maybe consider how the PLL's dependency on VBUS presence could be best handled ;-)

Regards

Mark