µTasker Forum
µTasker Forum => NXPTM M522XX, KINETIS and i.MX RT => Topic started by: creitzel on April 16, 2017, 04:50:41 AM
-
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
-
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
-
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
-
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
-
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
-
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
-
...
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
-
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 :-)
-
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
-
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
-
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 :-)
-
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:
../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.
-
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
-
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 :-)
-
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
-
Mark,
First let me give the good news. I just tried to do a build with FS USB MSD and SDCard support, using the changes you made to the code, and it works. I can see my SD Card, and I can even stream MP3's off of it, to both my PC and to my car stereo. :-)
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.
Forgive my ignorance here, I've done most of my work in application development, at a much higher level, much more removed from the hardware side of things. So, the terminology you're using is very new to me. I believe I understand what you are saying here though, let me know if I'm wrong. I understand what you just said to mean, that this chip, has a separate phase locked loop, to sync the physical usb clock against, and that PLL needs power on the USB connection to operate. Correct?
If so, I don't think you would even need any code to shut down that PLL, when the usb connection was removed, for the Teensy anyways, because the Teensy itself is powered from the USB connection, and when you disconnect it, it shuts down.
you could maybe consider how the PLL's dependency on VBUS presence could be best handled
I assume some of the other boards that your software supports are powered from other sources, and would then continue running, even though the USB was disconnected. The only thing I can think to do in that scenario, would be something like what you proposed. i.e. wait until the USB connection was initiated, and then initialize the PLL, and then hook into the USB disconnect, and shutdown the PLL in response to that event. You could write the code that way, and it should still work for the Teensy I think, it's just that the shutdown code would never get executed.
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
If I am understanding your request correctly, it should mean that all I need to do to test this on the Teensy, is to flip on the high speed USB define, and rebuild, and then try it on the teensy. I have just finished doing this, and I am still getting the same behavior I was getting before, when I tried the high speed test. i.e. the LED comes on, and stays solid for almost a full second, then briefly (probably like 100 ms at most) shuts off, then back on again for almost another full second. Also, the PC will not recognize the device at all. I don't even see windows trying to enumerate the device, in the message analyzer. So, it probably is the usb physical clock hung up, like you were saying.
So, I'm not sure how to proceed with the high speed thing, unfortunately, I don't have any kind of a debugger that I could hook to the teensy, to see what is going on inside. So, I'm totally dependent on the USB interface itself to communicate debug info.
I'm going to work on trying to get an emulated FAT working next, with the full speed mode, so that I can get the MSD requests into my code, and then I'll have to figure out what kind of backside transfer protocol I'm going to use, to transfer the data to the pi, and back. I'm still willing to do more testing, if I can help you with the HS side of things, so just let me know if there's something you want me to try. I've also got another idea on how to maybe help the process along, I'll shoot you a private message about it, in a bit :-)
Oh, and one more thing I noticed about your last round of changes, a few posts back, I mentioned a typo that I found in the source code for MSD
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),
As I did the diff to figure out exactly which files I needed to update in my dev version of the code, I saw that this typo was still there. I've fixed it in my dev codebase, but the USE_USB_CDC option won't compile with that line the way it is. Just a reminder :-)
Thanks again for all the help so far,
Chris
-
Chris
I had missed a couple of questions:
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.
To run at 180MHz rather than 120MHz, enable USE_HIGH_SPEED_RUN_MODE for the board in app_hw_kinetis.h. At this location the speeds of the system clock, bus and flash clocks can also be adjusted if desired.
Beware that 180MHz requires HIGH-SPEED-RUN mode to be used which has some restrictions, such as it is not possible to use internal flash programming. This is why I default to 120MHZ since that uses RUN mode, which doesn't have such restrictions.
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),
This was a spelling mistake, but it didn't cause a problem since the define matched. I had corrected it in the professional version last year, so I just checked it in to the open source one too:
"Correct spelling of USB_MSB_OUT_ENDPOINT_NUMBER to USB_MSD_OUT_ENDPOINT_NUMBER"
I understand what you just said to mean, that this chip, has a separate phase locked loop, to sync the physical usb clock against, and that PLL needs power on the USB connection to operate. Correct?
If so, I don't think you would even need any code to shut down that PLL, when the usb connection was removed, for the Teensy anyways, because the Teensy itself is powered from the USB connection, and when you disconnect it, it shuts down.
The teensy powers via the FS USB interface, which has nothing to do with the HS one. The high speed one is not connected to a connector but only to some holes in the PCB. To use HS I am assuming that one needs to solder an adapter to it.
See the teensy 3.6 circuit diagram and find the pins USB1_DM and USB_DP to see where they are connected to. There is also a solder bridge which connects a regulator (which is marked with a star and so is probably not mounted) to the HS USB's 5V line. I believe that this solder bridge needs to be modified in order to supply the VBUS to the HS USB's regulator (VREG_IN0).
Therefore I believe that the Teensy 3.6 needs always to be powered by the FS USB connection. It then needs an addition USB HS connection 'added' and if this is not supplying the VBUS -> VREG_IN0 signal it is normal that the HS driver will hang since it won't be able to starts its PLL, which is dependent on the VBUS voltage input.
If I am understanding your request correctly, it should mean that all I need to do to test this on the Teensy, is to flip on the high speed USB define, and rebuild, and then try it on the teensy.
This is only true if you have done any board modifications necessary and have wired up a connected USB connection to the HS interface.
If you haven't the HS mode won't be able to operate and will hang (if the second USB host's 5V signal is not present).
If you haven't prepared the HW it may be useful to check out whether the Teensy project supports HW use and whether there is a guide to modifying the board for it - maybe there is a small module that can be purchased to solder on to it(?)
I'm going to work on trying to get an emulated FAT working next
There is a guide at http://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf
as I'm sure I'm going to need some way of debugging my code
Most application layer debugging (once all HW interfaces are operational) can be done in Visual Studio - this is much faster and powerful than HW debugging.
The Teensy 3.6 doesn't have any Jtag debug capability (unless one adds a Jtag adapter to its lines, which is very fiddly). I would invest in a FRDM-K66F since it is quite cheap (not much more that a Teensy 3.6) and has an in-built HW debugger, complete HS USB interface, Ethernet, accelerometer and more and so can be used for all HW debugging. Later you can just switch the define from FRDM_K66F to TEENSY_3_6 to build for the final HW.
Regards
Mark
-
Mark,
To run at 180MHz rather than 120MHz, enable USE_HIGH_SPEED_RUN_MODE for the board in app_hw_kinetis.h. At this location the speeds of the system clock, bus and flash clocks can also be adjusted if desired.
Beware that 180MHz requires HIGH-SPEED-RUN mode to be used which has some restrictions, such as it is not possible to use internal flash programming. This is why I default to 120MHZ since that uses RUN mode, which doesn't have such restrictions.
Ah, that makes sense, thanks for the info :-)
The teensy powers via the FS USB interface, which has nothing to do with the HS one. The high speed one is not connected to a connector but only to some holes in the PCB. To use HS I am assuming that one needs to solder an adapter to it.
See the teensy 3.6 circuit diagram and find the pins USB1_DM and USB_DP to see where they are connected to. There is also a solder bridge which connects a regulator (which is marked with a star and so is probably not mounted) to the HS USB's 5V line. I believe that this solder bridge needs to be modified in order to supply the VBUS to the HS USB's regulator (VREG_IN0).
Therefore I believe that the Teensy 3.6 needs always to be powered by the FS USB connection. It then needs an addition USB HS connection 'added' and if this is not supplying the VBUS -> VREG_IN0 signal it is normal that the HS driver will hang since it won't be able to starts its PLL, which is dependent on the VBUS voltage input.
...
This is only true if you have done any board modifications necessary and have wired up a connected USB connection to the HS interface.
If you haven't the HS mode won't be able to operate and will hang (if the second USB host's 5V signal is not present).
If you haven't prepared the HW it may be useful to check out whether the Teensy project supports HW use and whether there is a guide to modifying the board for it - maybe there is a small module that can be purchased to solder on to it(?)
Ah, ok, that makes a lot more sense now. And I think it completely explains why I'm getting the weird LED behavior when I try to turn on HS USB, since I have no connector in place, it is hanging like you said, and that is producing the behavior I'm seeing. Again, sorry for my ignorance on these things, but I am learning a great deal as this project progresses. I will have to check for info on adding a HS USB connector to the teensy, and see what it would involve. I'm just getting started with the hardware side of things too, so I'm basically a noob at soldering too. If it sounds relatively straight forward though, I might give it a go. :-)
I'm not totally sure that I need HS USB, so far my tests I've run with the stereo, have been producing satisfactory/usable performance. That said, I only have about 20 MP3's on my SD card, and I'm not doing any proxying yet, so it will probably slow down a bit as I progress through the project.
There is a guide at http://www.utasker.com/docs/uTasker/uTaskerEmulatedFAT.pdf
Thanks for that, I will definitely check it out.
Most application layer debugging (once all HW interfaces are operational) can be done in Visual Studio - this is much faster and powerful than HW debugging.
I assume you mean by using the simulator in Visual Studio? Yeah, I was definitely planning on taking advantage of that. That said, My code never comes out perfect on the first try, and I anticipate, maybe, having to be able to dump some debug info while the code is running on the teensy.
The Teensy 3.6 doesn't have any Jtag debug capability (unless one adds a Jtag adapter to its lines, which is very fiddly). I would invest in a FRDM-K66F since it is quite cheap (not much more that a Teensy 3.6) and has an in-built HW debugger, complete HS USB interface, Ethernet, accelerometer and more and so can be used for all HW debugging. Later you can just switch the define from FRDM_K66F to TEENSY_3_6 to build for the final HW.
Pretty cool chip there. If I was planning on building multiple projects on the Teensy, that would definitely be a good investment. This is basically a 1-off project though, as I'm just building it for myself. That said, if it turns out that I need HS USB, and can't get it by modifying the teensy for some reason, that board looks like it might work in place of the teensy as well. (Probably overkill really, since I don't need all the extra hardware, but maybe they have another variant that I could use.) Good to know that there are some compatible options out there, and I wouldn't have to start all over again, if that happens.
Thanks for the great info. I'll try to keep ya up to date with the status of things. Especially if I do end up modifying the teensy for HS USB, and can do the testing you initially asked me for.
Chris
-
Mark,
Well, I've spent tonight working my way through the emulated fat tutorial, and poking around in the code that supports it. As a result, I have another question for you. :-)
From what I can see in the code, it appears that the emulated drive is entirely setup in memory, as arrays, when the program is initialized, and then those data structures are used to answer the USB MSD requests from the host.
I've been looking in the code, trying to figure out how, if it's possible, I would go about doing things dynamically. i.e. ideally I would want to be able to proxy requests for a specific file across my back side interface to the Raspberry Pi, so that I could then lookup the given path on the Pi's USB hard drive, and return the appropriate file.
I am not seeing a way to implement this within your current framework though, and I am wondering if I am on the wrong path here. Would it maybe be better for me to try to proxy the actual MSD requests across the back interface, and then attempt to implement those on the Pi side of the fence? Or is there something I'm missing in your emulated FAT layer, that would allow me to do what I want? Or maybe I could write a replacement for the emulated FAT layer that would allow me to do what I want?
If you were trying to implement my project, knowing what you know about your codebase, how would you go about attacking it?
Thanks in advance for any advice you can give me,
Chris
-
Chris
The emulated FAT uses const FAT content but not const data content. The data content can be taken form anywhere - also dynamically.
The FAT itself can't be dynamic because it is read in by the host on USB connection (that is, the host then has a local copy of the FAT and so knows how many files are available, their file objects and such. If this were to dynamically changed the host would not know about it unless the USB were enumerated again to synchronise it.
This means that your files (location, size, names etc.) must be fixed at enumeration. The content can be defined/generated when the host requests it.
The restriction of USB-MSD is that only the host may write. If the device writes (or changes things) after enumeration the host knows nothing about it because this is not something expected with USB-MSD and it can result in corruption if both sides could change things. There is no 'synchronisation' mechanism where the device informs the host that it has changed something apart from doing a complete new enumeration (disconnect/connect).
Regards
Mark
-
Mark,
The FAT itself can't be dynamic because it is read in by the host on USB connection (that is, the host then has a local copy of the FAT and so knows how many files are available, their file objects and such. If this were to dynamically changed the host would not know about it unless the USB were enumerated again to synchronise it.
This means that your files (location, size, names etc.) must be fixed at enumeration. The content can be defined/generated when the host requests it.
I was aware of the writing restriction, and I think I wasn't clear in what I want to do before. I understand the FAT must be static once the USB host has connected to the device, and that basically the host then owns the writing to the device. What I meant by dynamic is this:
I'm going to be using a USB external hard drive, plugged in to my Raspberry Pi, as a media storage drive. This drive's contents are read-only and fixed for any given running session of the system. (The contents on the drive will change from time to time, as I add/remove media files, but this will be done while the drive is disconnected from the car computer system, and is connected to my PC.) So, while the Pi, and the Teensy are connected to the drive, it is read-only, and the FAT is const.
The only other consumer of the drive, will be the Raspberry Pi, but it will also interact with it in a strictly read-only fashion (i.e. streaming the same media content via a wifi connection to my kids tablets/phones etc).
The problem I was trying to figure out a design to, within uTasker, is this: currently your emulated FAT code, has a hard coded array, down in the mass storage code, stored in RAM, with hard coded file names and sizes. I am going to have to build this FAT structure dynamically, when the device starts, by communicating with the Raspberry Pi, and enumerating the files on the USB drive. I'm not yet sure if I can do this in RAM, or if I will have to store it on the SD Card, as the FAT will probably be a decent size, because the drive has hundreds of folders, and thousands of files (currently about 30 GB of files, but will expand in the future I'm sure), all using long filenames.
So, I am trying to determine within your code, what functions/callbacks I have to hook, to pull this off. From what I've seen so far, I think I'm going to have to replace your const data, with function calls back to my code, that will communicate with the Pi, and return the results. Maybe I just need an initial function to build the FAT structure from the Pi, and then store it in RAM, or on the SDCard, and then use that to serve the USB. I'm really not sure yet, I was just asking if you had any pointers on which would be the easiest route to attempt, or how you would attempt to tackle a project like this, given your codes architecture. :-)
Thanks,
Chris
-
Chris
I haven't used the FAT emulation for some time so took a quick look at it to refresh my memory.
In fact I don't think that it is fixed in any way, as long as the define MAXIMUM_DATA_FILES is set to be adequate for your maximum requirement. mass_storage.c is not responsible for the files, just for managing the interface between the user code and the FAT emulation.
It is the application code that defines how many files there are, how they should be named, their length, etc. and later for passing data to be read from them when the host reads them. The application code is free to do this in any way it wants - the simplest being a cost method which is fixed for the product or else dynamically, based on whatever needs to control it.
In case of the reference it is the application that prepares the file list (see fnPrepareEmulatedFAT() in application.c). This has a fixed set in the reference but if you supply your own version of this routine (which is the idea) you can generate a list based on the present SD card content - you will just need to delay the start the USB task till after the SD card is ready and you have collected the list for insertion.
The functions that you need to support are:
- fnGetDataFile() to inform the mass storage task of the files that it wants to be 'visible'
uDatacopy() to pass data from these files to the mass storage task when it is feeding the USB-MSD with file content.
These functions may be used as they are (probably possible in most cases) or can be modified to do whatever else they need - like generating random file content or encrypting it, etc.
Therefore I don't in fact think that there are any restrictions; you just need to insert your own file list.
Regards
Mark
P.S. If you haven't done it before, set a break point in fnPrepareEmulatedFAT() to see the application setting a fixed list of files - imagine now how you could insert a dynamic list instead.
Then set a break point in fnGetDataFile() to see how the application informs the mass storage task of the list to be used. See whether that is already adequate once you have your file list ready, or else imagine how you could do this call back in a different way to suite your requirement. This is called for each file, until you terminate the list by returning 0.
Of course, do this in the simulator since it is called on each start.
P.P.S.
I moved this conversion to http://www.utasker.com/forum/index.php?topic=1938.0 since it otherwise mixed two topics.