USB-MSD with SD-card (Teensy 3.1)

Status
Not open for further replies.
Hi Steve

There are lots of devices that require Ethernet and an embedded web server can be achieved easily with 18k Flash and 10k of SRAM.
In production quantities cost is of importance and external devices add cost, weight, power consumption and size, making single-chip devices with Ethernet (and some with embedded PHY) popular.
The Freescale M52235, for example, has been very popular (with internal PHY) for about $5. 32k SRAM and 256k Flash is adequate for many industrial application - including MODBUS/TCP or Ethernet/IP where the stack fits along-side the application.

I have a simple AVR32 on-line at http://demo.uTasker.com which is running various applications including a TFT display that can be viewed on the web server - also FTP, TELNET and various other typical TCP services. It also supports IPv6 (global IPv6 [2001:470:26:105::99], although I think my provider's IPv6 tunnel is presently down). 80% of the Flash and 45% SRAM is still free for extensions. [I just checked - it has been up for 30 days and handled half a million frames since then]

A Kinetis K60 costs less that $5 and, together with a Micrel PHY, a crystal and RJ45 magnetics, allows a complete USB/Ethernet enabled device for under $10 and has ample room for many TCP/IP based applications and encrytion running happily together. Rarely does a full-blown application with USB and full TCP/IP support require much more than 120k of the 512k Flash space nor much more than about 32k of the 64k internal SRAM as in the cheapest parts.

When manufacturing say 10k units a year of such devices having full control of the stack (with Internet updates of TCP/IP protocols where needed) and lowest cost is very important. If you need to add say additional muticasting capabilities, VLAN or allow it to operate with multiple network addresses, or additional SNMP enterprise support to keep up with competitor's capabilities it can be done. If you are relying on a standard module to handle the stack you will have to pray that it does include it or that you can convince the manufacturer to build it in for you and somehow up-date the devices in the field.

Lantronix or Digi products (the uTasker TCP/IP stack is used in a similar one: http://www.xmodus.ch/sm_lan.html based on an ATMEL ARM7 with 32k SRAM) are popular for lab use where an extra $20 or $30 to hang on a ready-made stack is not an issue but once quantities go up the external module expense can be several times higher than the actual produts cost if were fully integrated. Usually it is rare to sell more than about 10..100 such devices to a customer since once quantities go up more an integrated TCP/IP stack makes more sense.

Regards

Mark
 
Last edited:
This is a good day,

I feel like I was bouncing of the walls and somebody finally opened a light. Mark, I see your project structure is really simple and helps to understand the CodeWarrior IDE and not having the Processor Expert makes me less uneasy too. I was thinking of getting a FRDM board too just for the heck of it, and try out the some examples. But then again with uTasker the simulation part is really awesome for that so if I don't get the right board, I can still work on other parts of the project (lets say TCP/IP if I don't order a FRDM that actually has the said stack on it).

And yes, at first I was checking out the WizNet chip and it's ease of design, like on the Arduino shield, seemed more fit and easier to integrate in my project, but on the long run makes less sense for all the reason mentioned in your last post. And I feel more comfortable upgrading to a K40 or K60 then trying to squeeze in another chip on my design. Ok, there will be so rerouting of signals to do, but I'm more confident that using uTasker and only changing some code in the config.h will do the trick, at least less complicated then integrating the Arduino stack and libs into a non-arduino project. For me, it was the next step anyways to have my design working with a more "professional" IDE that included JTAG debug and flashing, so I'm really glad to have found out about uTasker. More even I can use the Teensy to make that "bigger then anticipated" step but still, the support you provide is quite exceptional and for commercial products, that trust is everything.

Thank you very much Mark,
Mevon
 
Mevon

If you want Ethernet "on chip" you will need a K60 or K70 Kinetis and "today" there is no FRDM board with that.

- A tower kit is the nomal way to go - http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=TWR-K60D100M&fsrch=1

There are K60 modules here but they don't have built-in debugger and therefore need an external one like a J-Link (cheapest are Olimex Tiny for about $25):
http://www.elzet80.com/kbed.html

However Freescale will be unveiling a new FRDM board especially for IoT (Internet of Things) and I understand that it will have wired Ethernet on it. They say "Internet-ready, mbed™-enabled, ARM® Cortex®-M4 Freedom development platform" but won't give any more details until it is shown at TFT Americas on 7th April 2014. They have a design challenge taking place at the event: http://www.freescale.com/webapp/sps/site/overview.jsp?code=FTF_AMERICAS_MAKEIT

If you have started using the uTasker simulator you can already develop, test and debug Ethernet projects and there is usually no advantage of doing any work on the HW, so I would wait to see what the new FRDM board has to offer when it becomes available.

Regards

Mark
 
Lulz duff,

he already has ;P and yeah maybe I'll start a thread over there because here it is becoming less related to the subject. But still, I find it's a great exercise for everyone like me who got stuck to fact that Teensy 3 unlike Teensy 2, doesn't have a bootloader (yet... maybe I'll work towards that goal of making one and sharing it here, if everyone stays nice and polite *wink*) that permits serial com and mass storage device usb endpoints with a SD card. But yes, I'm also assuming that not everyone feels comfortable submitting a commercial product where Arduino is the ide. Even though it's well documented and there's a large community using and supporting it, it will always be the product of Arduino (TM) and who knows where they will be heading next and what changes they will make that can affect or not the Teensy or any other compatible dev board. So yes, it's really nice to have home made DIY libraries on multiple aspects of one micro controller for learning purposes, but it's even nicer to have an accessible all round professional solution that you can feel confident submitting to your boss. Lately, I have been in a hurdle with the Teensy and all I planed to do with the K20, but forums are for sharing solutions and wide spreading the support one can get to overcome said hurdles and maybe help others in similar situations. Thank you for understanding and your patience,

Yours truly,
Mevon
 
Last edited:
Hi Mark,

I've been reading a lot lately on project creation using CodeWarrior but I think my next question could be applied to any other IDE (Eclipse based or not I assume) :

What is the difference between FLASH and RAM based project?

I was thinking that normal projects should be build for the flash and in circuit, while the project is running, needed heap would be loaded dynamically in the ram as required by the running code. But is it for the case where you already have a bootloader running and new program is downloaded in the ram (or fitted to be running inside the ram)? Im guessing this is how arduino is running but we are not aware of because it's always build for RAM since arduino needs the bootloader to re-download new hex.. Then again, for the T3 there's a chip dedicated for that purpose only.

Thanks in advance,
Mevon
 
Mevon

There are often Flash and RAM targets and sometimes Release and Debug (for one or both of the first two targets).

- Release is typically a build with optimisation set high and debug output disabled, whereas debug is usually low optimisation to make debugging easier with some other debug output enabled (printf() type).
- Flash is intended to be programmed to flash and run there. RAM is intended to be downloaded into RAM and run there. Flash loading may be slower since the Flash has to be deleted and then programmed whereas RAM loading can be directly copied to RAM - also not disturbing the code that is already burned into the Flash. RAM debugging is often easier since debuggers can set a large number of breakpoints. Flash based debugging is limited to a few HW breakpoints that the chip supports and so is more resticted.

RAM debugging is only possible when there is adequate RAM available to fit the code and variables into and once the code gets too large the only choice is Flash debugging.
Both Flash and RAM targets can have a release and debug variant for the reasons mentioned. GCC code is difficult to debug when full optimisation is enabled since the code jumps around quite wildly (IAR on the otherhand have a compiler that produces 10..20% smaller code than GCC and debugging even with highest optimisation works very well - but is rather expensive). Personally I always use maximum optimisation with GCC when debugging and use the disassembler view to see flow control better since changing between debug to release can have other side-effects due to the code execution speed (i.e don't have "debug" targets as such).

Regards

Mark
 
Good day Mark,

So to put this in perspective, if I was to use your USB MSD + SD card bootloader, to have my additional functions or bits of code to work with the bootloader, I would have to use the complete project of the said bootloader and recompiled with my added code to have it all running inside the flash, as opposed to uploading my new compiled code to the RAM keeping the original bootloader intact and both would run at the same time? (same time : bootloader first, ram code after)

Many many thanks,
Mevon
 
Mevon

Bootloaders for small embedded systems don't load code to RAM. They give a possibility to upload code to the board's Flash as the MINI54TAN is doing on the Teensy.
A "standalone" bootload can upload any code and so doesn't have to be recompiled with added code; just as the MINI54TAN on the Teensy can upload "any" code.

The difference between having a bootloader loaded in the K20 is that it can work "without" the MINI54TAN being on the board. Since the Teensy has an "external" bootloader there is no big advantage of having an internal one with it, but an interal one would make sense for designs with only the processor.

The advantage of the MINI54TAN is that it doesn't occupy any Flash space whereby an internal loader will (depending on type for a few kBytes to up to about 25k). Projects using the MIN54TAN will be linked to 0x00000000 so that their reset vector is used to start from. Projects using a boot loader will be linked to a defined FLASH location after the boot loader and the boot loader then jumps to that location. That means that the main difference between a project working wit a boot loader is the link address used.

Boot loaders to RAM would only really be found in systems with SDRAM where they load code from NAND flash at startup to the RAM area where the program is then executed. Chips with SDAM controllers and NAND controllers for such operation are much bigger (in terms of price and performance and usually pin count) and are no longer single-chip solutions. Embedded Linux and other larger SW solutions are often used.

The K20 on the TEENSY 3.1 has 64k RAM and so can run "useful" programs from RAM (but limited compared to its 256k Flash capability) and so it would be possible to do the following (more as an experiment):
- Use a boot loader to select one of a number of projects compiled to operate in SRAM from a connected SD card
- Copy the file to SRAM and start the code from there.

If the program to be loaded can be controlled in some convenient way it would be possible to select which program to run and thus have the choice of a number of different programs to execute.

Regards

Mark
 
Hi Mark,

Thanks again for replying, I find this very educative. I was trying to solve the T3 USB MSD + SD card "trouble" (or solution) where everyone could use it from the Arduino environment. Now I understand a bit more what bootloaders are and really do. I guess I need to keep digging!

Thanks again,
Mevon

Edit: I dig this document too ;)

http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF
 
Last edited:
Mevon

I just saw that the Freescale Freedom board has been released today.
It has a 120MHz K64 with 256k SRAM and 1Meg Flash, 10/100M Ethernet with RJ45 and magnetics, Micro SD card with SDHC connection, USB host/device, RGB LED, an accelerometer and magnetometer plus an onboard SWD debugger as well as Arduino compatible connectors.
There are optional add-ons for Bluetooth and RF.

The board itself is available from a number of distributors but only Arrow has stock today - they cost $29 each. (Presumably heavily subsidised from Freescale ;-).
Freescale calls the K64 a "next-generation" Kinetis. And it does make the K20 look quite a baby in comparison!

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K64F&fsrch=1

Regards

Mark
 
Hi Mark,

All this is so interesting! And what a journey it is to dive into micro controller world in 32 bits! I mean I learned on Motorola 6809 and boy, 1 Mhz was so fast back then, learned everything I had to know about "computers", access RAM, data bus, etc. all made on wire wrap boards, those were the good days :p. Computers and electronics had forked in different ways back then and now they merge back again. And here we are, with a mere SoC, we have a tiny chip that is not a micro processor nor is it a micro processor, too big to be flip flop with memory and too small to be a full blown desktop computer. I guess Moore's Law is maybe closer to a sinusoidal than a proportional function.

Anyways, I'm really glad you shared your work with me and it help me quite a lot to understand this new world I plunged into lately. Now, I feel more like Neo in the Matrix, clueless as in the the first episode and I bet I will only make sense of it all when I turn blind (spoilers... sorry :p) Now, uTasker seems fantastic and I love the simulator but it seems all the functions I was looking for are used for programming purpose of the devices. Maybe I'm wrong but I feel I need to hack completely through your code to get the USB-MSD parts working with my code or own application. And also, the simulator only runs with the uTasker project, right? I cannot take any other project, put it in the Applications folder and run it in simulation... am I wrong here?

The thing is, I want to use the usb stack for my application: I plug my board (a T31 or my own home brewed board) in the usb port of any computer and I want to see it as a Mass Storage Device, to be able to drop files on it and use it with my app. Now it seems uTasker has the ability to do so but only for programming purposes, a bit like the MBED platform where you drop the hex in the folder and the target is reprogrammed with the new binary. Same thing with the Usb to Serial console, where it can receive the hex and ISP the code into the target.

For my application, I hoping for something different: a bootloader that would give me access to higher functionalities like sending or receiving ascii over usb, like a serial-to-usb endpoint; storing files on a SD card transferred over a usb msd endpoint; finally having a place to run my code as tasks that would be able to interact with the two first parts, and you know, return status to an app running on a PC and do something with the files I have in a directory on the SD card.

Maybe I'm wrong here, please advise!
Mevon
 
Last edited:
Mevon

>> but it seems all the functions I was looking for are used for programming purpose of the devices

That is true only for the boot loader application. Other applications use it in any way they want - for example see http://forum.pjrc.com/threads/25443-Teensy-3-1-based-sound-recorder-and-digital-delay-line which used the USB-MSD to copy sound recordings after the application has saved them to an SD card.

>>And also, the simulator only runs with the uTasker project, right?

It will simulate any code that is put into the project as long as long as the hooks to the HW simulator are not bypassed. (Eg. if the code accesses a port without using the port hook the peripheral simulator will not know about it but as long as it uses the correct hooks it will). If there is no direct HW access by the application (eg. it is performing algorithms) it doesn't have any restrictions.

Regards

Mark
 
Hello Mark,

Overwhelming this uTasker, as usual! I've been trying to look into this example of the delay line you mentioned, but can't seem to find it anywhere in the files. I've looked into the forum and found a note in the uTasker 1.4.3 release but again no file or code. I got the "fnSaveWavToDisk" function but I think there's more to it then just a file saving function. I know it is a bit complex to go through every little details needed to get the whole project working as a delay line adc/dac but this would make a great example for me to understand more how the uTasker is working.

I've been testing my luck lately with the CW IDE and the PEx components and it gets more and more easy with time ( and with Erich Styger *.PEupd files ;) ). I got to say we are lucky to have people like him and you, and Paul S. paving the way for us because the road to success is pretty harsh when you start from scratch and don't have multi millionaire budgets.

Thanks again for you great support,
Mevon
 
uTasker said:
I also don't understand why you would want to avoid Freescale Codewarrior. It is free up to 128k code size (special edition which is even supported by Freescale in case you have questions or difficulties) which is enough for most work
Click to expand...
What limitations are on the free version (not the 30 day trial) of CodeWarrior w/Eclipse? Other than the 128KB code size? For students/hobbyists, does it makes sense, in terms of a free large suite of contributed libraries as in Teensyduino? With a bare-metal IDE and not much more than a C/C++ startup program, is it viable? And the freebie software from Feescale... would it be written with dependencies on Freescale development system hardware? This is the usual case.
 
Last edited:
Hi Steve,

Yeah I know I was silly :p CW IDE is ok, I'm using the 10.6 and submitted for the new Kinetis Designer Studio http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=KDS_IDE&fpsp=1&tab=Design_Tools_Tab which is in beta right now. I just hope I don't get busted in 30 days after the licence expires and have to pay 500$+ to use it. I was thinking that the free version and the trial version was the same, maybe somebody can confirm that ( or I will be able to tell you in 28 days now... ;) ). Like I said, thank god for this website which is full of resources if you have the time to dive deep in it : http://mcuoneclipse.com/

But I like to have the uTasker as plan B if cannot succeed on my own with tools I already have at my disposal. It's juste for me now it is somehow too huge of a project to really understand all I have to do in order to get my project up and running. And the PEx is really easy to grasp when you start to get familiar with the IDE. Downside is your are really a sad kid if you don't have all the components already available for your MCU. I know there's a lot for the T3 because there's an inexpensive Freedom board with the same cpu (mk20dx128vlh5) http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-K20D50M so lots of examples and components are available but for the K20D72 the demo board is like 150$ so not much is done yet. I suggest if you want real bare-metal with hardcore low level prog, try the uTasker. But if you want easy breezy beautiful GUI kind of action, ProcessorExpert and KDS is the way.

Best regards,
Mevon
 
It sounds as though Freescale's complimentary KDS will be the tool of choice in the future (for Kinetis users):
- https://community.freescale.com/message/396727#396727
- https://community.freescale.com/message/395981#395981
effectively replacing Codewarrior.

>>delay line adc/dac
Go to ADC_Timers.h and enable TEST_AD_DA and that will configure and start ADC->PDA->DMA->DAC operation.
Since this is all HW controlled there is not a lot involved - just really the call fnConfigureADC()

If saving to SD card (or just for the hell of it) the half-buffer full interrupt half_buffer_interrupt() will fire (every 500ms with 8k sample buffer) and trigger an event to cause the file system write.

Regards

Mark

>> Mevon. If you have a full version that is in evaluation mode it will simply stop operating after that period (saying that the license can't be found). Just uninstall it and install the special edition instead. As far as I am aware there are no further restrictions in the Special edition apart from the 128k code limit. But even then you can simply build with GCC (which is what CW is using anyway).
 
Mevon

I mentioned that I wanted to make a video to help starting with CodeWarrior and I finally managed to do it: http://youtu.be/uBbiw36Caq4

The Teensy 3.1 is visible right at the end (but dwarfed by a lot of other Kinetis boards)...

Regards

Mark
 
Hi Mark,

Nice I will look into this too! Now here is where I'm at, the PEx and CW MCU 10.6 are working fine but I was planning to use the Teensy Loader to test out my T3 code I generated but I was fumbled by the srec vs ihex conundrum. Seems everywhere I look, CW MCU is supposed to be able to generate the intel hex or motorola s-19 hex files but when I look in the settings (project properties) either the linker or compiler the magical checkbox is nowhere to be found. I see you circumvented the problem with your generate.bat file but then again you make some srec, which I assume is for any other 3rd party flash programmer then the Teensy Loader. And when I look into the Teensyduino Makefile, I see "$(OBJCOPY) -O ihex -R .eeprom $< $@ " in the elf/hex section, which makes me assume it needs to be intel hex to be used with Teensy Loader. And judging from this post : http://mcuoneclipse.com/2013/07/21/diy-free-toolchain-for-kinetis-part-2-eclipse-ide/, it is kind of the same way you did but without the batch file. Can you confirm that the Teensy Loader needs intel hex file format?

Thanks for everything,
Mevon
 
Mevon

Some versions of CW have check boxes for generating binary or hex outputs but some don't. Rather than rely on such things simply use a post build step (bat file).
The following will generate binary, srec and ihex outputs:

arm-none-eabi-objcopy --output-target=binary uTaskerV1_4.elf uTasker_V1.4.bin
arm-none-eabi-objcopy --output-target=srec uTaskerV1_4.elf uTasker_V1.4.srec
arm-none-eabi-objcopy --output-target=ihex uTaskerV1_4.elf uTasker_V1.4.hex

The .hex (intel hex) format is required with the Teensy loader.

Beware that this format should NEVER be loaded using Codewarrior since it will assume that the content is binary and then programs the ASCII hex directly to the chip - the results is that the flash configuration area gets programmed with whatever happens to be there - some thing like "S21400047012E00A4A1368988EC20708D50BE00120DE" which will usually activate flash sector protection and, in the worst case, can even lock the JTAG so that the chip can never be programmed anymore.

Recovering from the flash protection state is not difficult as long as one knows how: For the record, to recover with CodeWarrior Flash utility one sets an additional option in the connection setting to "Always mass erase on connect" and then all flash sectors are unlocked on debugger connection.

Regards

Mark
 
Status
Not open for further replies.
Back
Top