mercury0x0d
Member
Hello, all!
I'm heading up a project to put together prototypes of a device which my group is designing around the Teensy 4.1, and I'm writing here to solicit advice on the best way to go about safely integrating a Teensy (or at least the CPU which powers it) when/if the device goes to full production. As mentioned, the device will use either a real, physical Teensy 4.1 or a "virtual" Teensy - an i.MXRT1062 microcontroller paired with a Winbond flash memory chip and the MKL02 bootloader chip, all integrated into the PCB of our finished product.
As our finished device is likely to get new features and bug fixes down the road, we would like to make the "firmware" (merely the the code running on the embedded Teensy) easily upgradable by the end user. By design, our finished device will be left connected to the user's computer as part of its use, and the concern is that, if the user also happens to be programming an actual standalone Teensy of their own which they also have connected to their PC at the time, they may accidentally send their newly compiled sketch to the Teensy embedded in our product as opposed to the Teensy they intended to program. This would be a Very Bad Thing, and we want to eliminate the possibility of it happening. I seem to remember reading somewhere in the Teensy documentation that the bootloader only responds to automatic programming requests if an option is selected on the "USB Type" submenu of the Arduino IDE's "Tools" menu which includes "Serial". We will be using this serial port for some parts of our device's functionality, however, so it will need to remain enabled.
And thus, I'm wondering... is there any way to leave the Teensy bootloader in a "disabled" state by default so that it will not respond to incoming programming requests, but yet leave the basic functionality present so that the user may still easily update the code at a later date by re-enabling it temporarily? We definitely do not want our end users to feel that they need to disconnect our device each time they need to program their own microcontroller to avoid confusion, or have to press some kind of "disengage" button a'la the handy little device Paul made; the preferred way of dealing with this issue is to include a menu option in our product titled "Update firmware" which will allow the bootloader to accept incoming programming for a short time only to have that ability safely blocked once again after the Teensy reboots into the newly installed code.
I'm aware of the security features of the Teensy 4.1 which allow you to lock your code so that it cannot be extracted from the device, but that would also prevent people from updating the code later on (at least to my understanding - correct me if I'm wrong!) so it is not an option for our use case. I believe there are also fuses which can be set in the Teensy itself which will disable this function entirely, but that obviously is also not suitable for our needs.
If this is not possible, then I'm curious as to why. Is it only because some specific pin to allow doing so is simply not broken out onto the externally available pins of the Teensy? In other words, perhaps this would be technically possible when making your own PCB, but just cannot be done with the Teensy as it exists in its manufactured state. If that is the case, perhaps we would be better off simply using a "virtual" Teensy as mentioned above. Or, would it somehow help if we removed the bootloader entirely? Granted, we would then have to come up with some separate method of upgrading the firmware, but if we have to, we have to, I suppose.
On the topic of making your own Teensy-compatible, I did check out these links already:
https://www.pjrc.com/store/ic_mkl02_t4.html
https://forum.pjrc.com/threads/70978
https://forum.pjrc.com/threads/799-Firmware-loader-for-Teensy-3?p=1783&viewfull=1#post1783
https://forum.pjrc.com/threads/24063-Paul-Teensy-in-a-commercial-product?p=34451&viewfull=1#post34451
...but I'd still appreciate any tips or tricks that could be thrown my way by anyone who has already gone this route before, should this end up being the path we end up taking.
I'd love to hear any ideas with which you folks can come up, and thanks in advance!
I'm heading up a project to put together prototypes of a device which my group is designing around the Teensy 4.1, and I'm writing here to solicit advice on the best way to go about safely integrating a Teensy (or at least the CPU which powers it) when/if the device goes to full production. As mentioned, the device will use either a real, physical Teensy 4.1 or a "virtual" Teensy - an i.MXRT1062 microcontroller paired with a Winbond flash memory chip and the MKL02 bootloader chip, all integrated into the PCB of our finished product.
As our finished device is likely to get new features and bug fixes down the road, we would like to make the "firmware" (merely the the code running on the embedded Teensy) easily upgradable by the end user. By design, our finished device will be left connected to the user's computer as part of its use, and the concern is that, if the user also happens to be programming an actual standalone Teensy of their own which they also have connected to their PC at the time, they may accidentally send their newly compiled sketch to the Teensy embedded in our product as opposed to the Teensy they intended to program. This would be a Very Bad Thing, and we want to eliminate the possibility of it happening. I seem to remember reading somewhere in the Teensy documentation that the bootloader only responds to automatic programming requests if an option is selected on the "USB Type" submenu of the Arduino IDE's "Tools" menu which includes "Serial". We will be using this serial port for some parts of our device's functionality, however, so it will need to remain enabled.
And thus, I'm wondering... is there any way to leave the Teensy bootloader in a "disabled" state by default so that it will not respond to incoming programming requests, but yet leave the basic functionality present so that the user may still easily update the code at a later date by re-enabling it temporarily? We definitely do not want our end users to feel that they need to disconnect our device each time they need to program their own microcontroller to avoid confusion, or have to press some kind of "disengage" button a'la the handy little device Paul made; the preferred way of dealing with this issue is to include a menu option in our product titled "Update firmware" which will allow the bootloader to accept incoming programming for a short time only to have that ability safely blocked once again after the Teensy reboots into the newly installed code.
I'm aware of the security features of the Teensy 4.1 which allow you to lock your code so that it cannot be extracted from the device, but that would also prevent people from updating the code later on (at least to my understanding - correct me if I'm wrong!) so it is not an option for our use case. I believe there are also fuses which can be set in the Teensy itself which will disable this function entirely, but that obviously is also not suitable for our needs.
If this is not possible, then I'm curious as to why. Is it only because some specific pin to allow doing so is simply not broken out onto the externally available pins of the Teensy? In other words, perhaps this would be technically possible when making your own PCB, but just cannot be done with the Teensy as it exists in its manufactured state. If that is the case, perhaps we would be better off simply using a "virtual" Teensy as mentioned above. Or, would it somehow help if we removed the bootloader entirely? Granted, we would then have to come up with some separate method of upgrading the firmware, but if we have to, we have to, I suppose.
On the topic of making your own Teensy-compatible, I did check out these links already:
https://www.pjrc.com/store/ic_mkl02_t4.html
https://forum.pjrc.com/threads/70978
https://forum.pjrc.com/threads/799-Firmware-loader-for-Teensy-3?p=1783&viewfull=1#post1783
https://forum.pjrc.com/threads/24063-Paul-Teensy-in-a-commercial-product?p=34451&viewfull=1#post34451
...but I'd still appreciate any tips or tricks that could be thrown my way by anyone who has already gone this route before, should this end up being the path we end up taking.
I'd love to hear any ideas with which you folks can come up, and thanks in advance!