[ MINI54TAN purpose ]
- Thread starter texane
- Start date
- Status
PaulStoffregen
Well-known member
No, the MK20 chip does not have a bootloader stored in its flash memory. It's stored in the Mini54. This design allows your program to use the entire MK20 chip.
Hi Paul,
This is my first post so let me say thanks for your hard work. Teensy is amazing, I've used it for personal and professional projects.
My question is regarding the support that the MK20 chip gives to the MINI54 during programming. The MINI54 has no USB connection, so inferring from your schematic, it looks like the following is happening:
USB packet -> MK20 -> (out pins 37,38) MINI54 -> (out pins 21, 25) MK20 (EZport)
Thus the MK20 must participate in its own programming by supporting the USB connection. The reason it concerns me is that I'm trying to figure out a way to program the Teensy 3.1 over it's serial port. That way I can reconfigure it using an XBee which is a nice-to-have in my application. My concern is that if I mess up after a full chip erase the USB portion of your bootloader will be missing and therefore my Teensy will be bricked. Is that the case? Could the firmware that supports programming be squirreled away somewhere else, like a ROM?
Thanks for your help and support!
./mike
PaulStoffregen
Well-known member
I'm not going to comment on the internal Mini54 details. But let's chat about this bit...
Hypothetically speaking, and even before doing so, let me be perfectly clear that this conversation in no way implies I'm ever going to implement such a feature, but nonethless, hypothetically, if Teensy 3.x someday supported a way to reprogram wirelessly by Xbee or other serial communication, how would you propose programming mode be initiated? By this, I mean initiated automatically, without pressing the pushbutton. My assumption is wireless remote reprogramming probably isn't very useful if it can't be wirelessly initiated.
USB auto-reboot works for 2 reasons, neither of which applies to serial communication.
#1: The USB port is automatically initialized and running when your Arduino sketch runs. During the first second or two, the USB host is still "enumerating" the device, but from Teensy's point of view, the USB is always up and running and could receive the reboot request at any time. USB has dedicated pins that aren't ever used for normal I/O. USB also has a fixed baud rate and communication format. Serial lacks all of these features. It doesn't start communicating until you use Serial1.begin(baud). The pins are shared with normal I/O and other important features, so you can't always automatically start Serial without seriously disrupting other potential applications that would use those pins for non-serial stuff. Serial also lacks consistent data rate, data format, so you don't even know in advance what baud rate is needed.
#2: USB has a well defined data format that supports multiplexing many virtual data streams (called endpoints), and also has a message delivery mechanism (endpoint zero) which runs simultaneously. Control messages can be sent to request a reboot, without disrupting the other streams, as seen by the application code running on Teensy and also on the PC or Mac that's communicating with Teensy. Serial lacks all of this. It's just a single stream of bytes.
Arduino uses one of the serial handshake pins to cause entry to bootloader mode. Were you imagining connecting an extra wire, solely for the purpose of initiating programming mode?
If you go messing with this stuff in unsupported ways, you may indeed brick your Teensy. I don't want to discourage you from hacking and experimenting, but you really do need to accept responsibility for damage if you go down this path. My advise is this: buy spares!
If you do try this stuff, another good idea would be carefully saving a copy of the code and steps you're using on each attempt. If you do end up bricking a Teensy, at the very least keeping good notes can help you avoid making the same mistake again on your spares. It's also give you something you could send to me, which won't necessarily do any good, but the odds of a positive response from me are far better than a poorly described "something went wrong" report.
Hypothetically speaking, and even before doing so, let me be perfectly clear that this conversation in no way implies I'm ever going to implement such a feature, but nonethless, hypothetically, if Teensy 3.x someday supported a way to reprogram wirelessly by Xbee or other serial communication, how would you propose programming mode be initiated? By this, I mean initiated automatically, without pressing the pushbutton. My assumption is wireless remote reprogramming probably isn't very useful if it can't be wirelessly initiated.
USB auto-reboot works for 2 reasons, neither of which applies to serial communication.
#1: The USB port is automatically initialized and running when your Arduino sketch runs. During the first second or two, the USB host is still "enumerating" the device, but from Teensy's point of view, the USB is always up and running and could receive the reboot request at any time. USB has dedicated pins that aren't ever used for normal I/O. USB also has a fixed baud rate and communication format. Serial lacks all of these features. It doesn't start communicating until you use Serial1.begin(baud). The pins are shared with normal I/O and other important features, so you can't always automatically start Serial without seriously disrupting other potential applications that would use those pins for non-serial stuff. Serial also lacks consistent data rate, data format, so you don't even know in advance what baud rate is needed.
#2: USB has a well defined data format that supports multiplexing many virtual data streams (called endpoints), and also has a message delivery mechanism (endpoint zero) which runs simultaneously. Control messages can be sent to request a reboot, without disrupting the other streams, as seen by the application code running on Teensy and also on the PC or Mac that's communicating with Teensy. Serial lacks all of this. It's just a single stream of bytes.
Arduino uses one of the serial handshake pins to cause entry to bootloader mode. Were you imagining connecting an extra wire, solely for the purpose of initiating programming mode?
If you go messing with this stuff in unsupported ways, you may indeed brick your Teensy. I don't want to discourage you from hacking and experimenting, but you really do need to accept responsibility for damage if you go down this path. My advise is this: buy spares!
If you do try this stuff, another good idea would be carefully saving a copy of the code and steps you're using on each attempt. If you do end up bricking a Teensy, at the very least keeping good notes can help you avoid making the same mistake again on your spares. It's also give you something you could send to me, which won't necessarily do any good, but the odds of a positive response from me are far better than a poorly described "something went wrong" report.
My vision is not to implement a generic way to reprogram Teensy over Xbee. My application uses Xbee for a command-and-control protocol. I would implement a "Reflash" command in it that could do something like this:
1. Copy the contents of the reflash routine to SRAM.
2. Branch to the SRAM copy of the routine
3. Perform a chip erase
4. Flash and verify the new program
5. Reboot
I fully accept the consequences of messing with flash (and I have spares!). My question maybe should have been: Will your loader work even when the MK20 erased? If so I have a good chance of rescue reprogramming my Teensy. If not, do you have an ISP dongle that you use for the initial programming or debugging?
Thanks for your support!
./m
PaulStoffregen
Well-known member
Yes, it will work. No part of the bootloader code is stored in the MK20 flash.
However, you must be careful with the byte at 0x0000040C. When the MK20 resets, the hardware reads that byte and configures the chip before coming out of the reset state.
I highly recommend you use flash command 0x44 to erase the chip. It's much safer than 0x08 or 0x09. Also, I'd highly recommend adding code to your write routine and avoid reprogramming location 0x0000040C. The Teensy 3.1 bootloader does this, so 0x0000040C can't be changed, even if your HEX file has a different byte.
If you program 0x0000040C with the wrong bits, you'll almost certainly brick your Teensy.
EDIT: the flash config byte is at 0x0000040C, not at 0x0000041C as this message originally said.
Last edited:
In step 4, would the new firmware be stored on, say, a micro SD card? The new code was received by any means: tennis shoe, ethernet, various forms of wireless and put on the SD card.
Or, and as how I once did it, a firmware updater program was written to a dedicated sector of main flash - and invoked at will as a stand alone entity. To avoid adding SD card or a flash chip, that ever-present loader does an in-place replacement of the firmware using a stream of data from LAN/wireless. No intermediate store. If the stream is disrupted, the loader simply restarts (a session with a server). If done very carefully, with watchdogs and CRCs, this works.
Alas,
I too would like the means to remotely via LAN or wireless media replace the contents of the Teensy 3.1 flash - firmware update. The current Teensy does so only with USB.
The best way would be to extend the USB method with other than a computer as the USB host. But that leads one to too much added hardware (USB host, etc).
The Anarduino miniWireless PCBs (AVR mega328 for Arduino) and the Moteino (also a mega328) have an onboard large but cheap SPI flash chip (megabytes). Moteino's "dualOptiBoot" uses the image in the flash chip to update the MCU's flash from the external flash chip (same as if it were an SD card, but cheaper). But this presumes the mega328 boot can (and does) get the program code from either serial port (or USB) or from the flash chip.
With the Teensy 3.1, one could work out how to reserve a bank of flash in which to store the equivalent of dualOptiboot - using serial or flash chip/card. Perhaps too via the USB connection as in standard Teensy 3.
But these unattended remote firmware updates might often be where the USB port on the Teensy has no link to a host PC. That would be the basic concept.
In my case the new firmware would come over the air. The MK20 has a fairly fine granularity for erase operations on it's program flash, however you cannot perform any read operations on the program flash while a program or erase operation is pending. (See section 28.4.9.4. Allowed Simultaneous Flash Operations, p.597 of the datasheet). Therefore you must be careful not to touch flash in your bootloader. This is quite different from the way that the AVR chips work. They have a split flash architecture with a bootloader section that works while you're flashing the rest.
My strategy is to be executing entirely out of SRAM while I do my reprogram. There are a few subtitles here that are worth mentioning:
1. You must either disable interrupts or move your interrupt vectors into SRAM
2. You must be able to do instruction fetches from SRAM (this isn't yet working for me)
3. Your flash routine can not return, ever.
Dual boot might work. Really that would mean having two programs in flash with separate address spaces. The first would check the rest of memory for a valid program and branch to it. It's more of a trampoline than a bootloader. That program would "do something smart" if it saw that the flash was messed up.
Cheers
./m
I'll ask this in the form of a question: If you have code stored in the main flash that can pull firmware from somewhere on some communications medium, then why do you need to copy it to RAM and execute it there? You can't overwrite the flash where that code was, originally, because the RAM resident code may fail to finish due to a comms fault.
That's why I said that the updater has to live in a portion of the MCU's main flash that by agreement is never overwritten by newly downloaded firmware.
NXP calls this a "secondary bootloader" - as the primary is in ROM but is serial port only (or USB). A user written secondary loader is invoked by the primary loader in ROM. The user's secondary loader is normally using ethernet or a wireless device of some kind.
This is what I'd like to see in the Teensy - some way for users to write a secondary loader in MCU flash in a sector by agreement is never erased.
That's why I said that the updater has to live in a portion of the MCU's main flash that by agreement is never overwritten by newly downloaded firmware.
NXP calls this a "secondary bootloader" - as the primary is in ROM but is serial port only (or USB). A user written secondary loader is invoked by the primary loader in ROM. The user's secondary loader is normally using ethernet or a wireless device of some kind.
This is what I'd like to see in the Teensy - some way for users to write a secondary loader in MCU flash in a sector by agreement is never erased.
Last edited:
My interpretation of the datasheet section that I mentioned before is that while ANY area of program flash is being written or erased NO area can be read. Thus, the flash cannot program the flash.
Cheers
./m
I have configured my arm-none-eabi gcc to compile code for MK20 and I am using it sucessfully with my Teensy 3.1 board. I have not found any reference to that "41C" address into the MK20 datasheets. 40C is the flash security field into the flash configuration field. Did you mean this?
Thanks for your great work and thanks in advance!
Last edited:
potatotron
Well-known member
You can't use an AVR programmer; the MK20 is an Arm chip and doesn't speak AVR.
If you're asking if you can design a circuit using a MK20 but not use a Mini54 then yes; strictly speaking it's not required. You'll need some way to get your program into a blank chip, there are options ranging from slightly complicated to very complicated.
Why would you want to do that? The Teensy has the MK20 to make everything very easy for you.
I don't want the board, just the chip. However, I already own about 6 teensy 3.x's
PaulStoffregen
Well-known member
Yes, you can buy MK20 chips from Freescale and use them without buying anything from PJRC. Of course, I hope you'll need Teensy along the way for prototyping & pre-production tests, early customer samples, etc. If you're going to manufacturing only a relatively small volume of products, like less than 100-200 per month, I also hope for your sake you'll seriously consider the hidden costs of whatever approach you take. Every product and every business is different, but a common theme for success involves focusing on marketing and product features/refinement first, and later cost reductions when the well-established sales volume justifies the NRE expense.
For directly programming the MK20 chip, without anything from PJRC, you probably want to look at P&E Micro. I can't answer any questions about their products. But given their prices, especially for the ones recommended for production use, hopefully they'll be willing to help you. Looks like they even have a forum. Maybe ask there?
For directly programming the MK20 chip, without anything from PJRC, you probably want to look at P&E Micro. I can't answer any questions about their products. But given their prices, especially for the ones recommended for production use, hopefully they'll be willing to help you. Looks like they even have a forum. Maybe ask there?
Thanks Paul. and don't worry, I'm a PJRC customer for life...in fact, I just placed another order this afternoon. But my current project requires maximum power in a minimum PCB footprint. I'm venturing out into uncharted territory, personally speaking, so I appreciate the advice.
potatotron
Well-known member
One option would be to split the design into two circuit boards -- one with the Mini54 (and USB connector, if you don't need it normally) and the main board with the MK20 etc. main circuit.
hello,
I'm also struck in same situation. I've 4 teensy3.1, I developed complete POC using teensy3.1 board with teensyduino only (it works great and developed in very good size). my application required further reduction in size (application is body Implants), so I'm planning to make custom board by separating mini54tan. so is there any chance to use only MK20DXxxx chip with its necessary components. I planning to buy Mini54TAN chip from PJRC and manufacturing custom programming board with only mini54, which will help me to boot the program in every chip by linking mini54 board and MK20 board physically..
Please Share your comment to choose correct path.
Thank you WMXZ for your reply....
Yes I'm aware of MKL02Z32VF chip used for boot loader, either of those pre-flashed chip would be useful for flashing hex file in MK20DX256 chip..
Just I'm not getting how to flash the code in MK20DX256 , if I want to use only MK20DX256 chip..
PaulStoffregen
Well-known member
It's hard to imagine many connectors with sufficient number of pins that take less space than the 16 square mm of the Mini54. But the new chip will be available in a couple weeks, requiring only 9 square mm.
Of course, if you only need initial programming, this lets you buy only a few chips from PJRC. That's fine, really.
If size really is your primary goal, and you can wait a few weeks for the new chip, I think you should seriously look at whether the connector you're considering is really smaller than 3x3 mm, not to mention its height.
If the cost of the chip is a motivation, that's fine too. Teensy is a prototyping platform meant to help you get your project or product launched. I really do want you to make the best choice that fits your needs!
Last edited:
hey Thanx PAUL for wonderful suggestion..
yes, cost will also be the issue later on... hence I must use MK20DX256 chip only.
May be my custom board is copy of teensy 3.1 just instead of soldering MK20DX256 chip i'll solder TQFP to DIP adapter
over board and I'll use this board to flash code in MK20DX256 chip. After flashing code, I'll remove the chip from adapter and solder it over my PCB.
Is this right way to go further...
thank you
yes, cost will also be the issue later on... hence I must use MK20DX256 chip only.
May be my custom board is copy of teensy 3.1 just instead of soldering MK20DX256 chip i'll solder TQFP to DIP adapter
over board and I'll use this board to flash code in MK20DX256 chip. After flashing code, I'll remove the chip from adapter and solder it over my PCB.Is this right way to go further...
thank you
- Status