What conditions must be met for the teensy loader to work?

Status
Not open for further replies.
I believe I have mostly gotten a DFU bootloader working on the Teensy 3.1 at this point :).

I do this by uploading an application to 0x2000 and setting the stack pointer and program counter to the I.V.T. at that address.

As far as I am aware, there is no way to over-write the security bits this way, as my linker script should have them at 0x2400 instead of 0x0400.

Code:
EMORY
{
	APP_FLASH (rx) : ORIGIN = 0x00002000, LENGTH = 248K
	RAM  (rwx) : ORIGIN = 0x1FFF8000, LENGTH = 64K
	FLEXRAM (rwx) : ORIGIN = 0x14000000, LENGTH = 2K
}
SECTIONS
{
	.text : {
		. = 0;
		KEEP(*(.vectors))
		*(.startup*)
		/* TODO: does linker detect startup overflow onto flashconfig? */
		. = 0x400;
		KEEP(*(.flashconfig*))
		*(.text*)
		*(.rodata*)
		. = ALIGN(4);
		KEEP(*(.init))
		. = ALIGN(4);
		__preinit_array_start = .;
		KEEP (*(.preinit_array))
		__preinit_array_end = .;
		__init_array_start = .;
		KEEP (*(SORT(.init_array.*)))
		KEEP (*(.init_array))
		__init_array_end = .;
	} > APP_FLASH = 0xFF

(if I understand correctly, .text inherits its base address from the memory map --if it doesn't, I am an idiot and obviously may have corrupted the security bits).

Yet, I managed to make the Teensy unresponsive by foolishly uploading a broken program to it, and doing so without having the bootloader check for say, a low pin to force DFU mode, before entering the application at 0x2000.

Resetting the device using the button does not seem to be working. I have bodged some wires onto it for a manual bulk erase, but am waiting for a J-Link to arrive.

I am curious, under what conditions --apart from the obvious ones of wrongly setting the security bits-- will the teensy become unresponsive?

Must there be some form of HID device present for the MINI54 to engage its erase feature?
 
Last edited:
There are 2 issues.

1: The most serious is if you program FSEC to disable access to the memory and to also disable mass erase. When you press the Program button, the MKL02 chip (not MINI54, which was used on the long discontinued 3.0 & 3.1) will try to perform a mass erase if it can't access the chip. If you've also disabled mass erase, then it's forever locked out. If you haven't built in a mechanism into your own code to erase or recover, your board will be permanently locked to whatever you wrote.

2: The less serious issue is with FOPT which controls the NMI pin. By default the bootloader programs bit #2 so NMI is disabled. If you erase this byte, NMI becomes active. If you connect circuitry which drives pin 33 low, NMI can interfere with running the bootloader. Same with your own code... NMI is a nightmare to use. Fortunately that pin has its pullup resistor enabled by default at reset, so this is a non-issue if you leave the pin disconnected.
 
That's why I am puzzled, the FSEC Bits are set such as to enable mass erase.

Code:
0x40, 
// = 0b0100 0000
// Disable Backdoor, Enable Mass Erase, Grant Factory Access, Enable Flash Security

However, I did notice that I did have NMI enabled. Pin 33 is not externally driven as this is a bare teensy 3.1 board, but perhaps this could be problematic.

Code:
// [7-3] Reserved
// [2] NMI Disable. 0 = NMI Interrupts Blocked. 1 = Enabled NMI.
// [1] EZPORT Disable. 0 = Dis, 1 = Enable

0xFF, //NMI and EZPORT Enabled

Even more puzzling, I have set the Program flash protection to 0xFFFFFFFE, which, protects 0x0000 to 0x2000. To my understanding that would prevent any subsequently uploaded programs from executing writes to the flash config bytes, unless changed via mass erase.

As a precautionary measure, I also check to see if IVT[1] (the program counter) points to somewhere outside APP_FLASH and reject the application if it does. This should also keep execution out of the bootloader flash.
 
Last edited:
The plot thickens,

I used the J-Link on the MK20's serial wire debug lines to preform a mass erase --which was successful, and thereafter, flash my bootloader.hex file onto the MK20, which was also successful. I can read back what I wrote, byte for byte, and the code runs successfully.

I then pressed the reset button and the MK20 was wiped clear --the bin file I dumped from it was all F's.

However, it was still not detected by teensy loader.

I'm pretty stumped -- any ideas?
 
Have you tried the 15-seconds (or was it 10?) reset procedure? (sorry, don't have a link, at the moment)
 
There is a '15 sec button hold processor reset' built into T_3.5 and T_3.6 - haven't caught any note that same option exists for others?
 
There is a '15 sec button hold processor reset' built into T_3.5 and T_3.6 - haven't caught any note that same option exists for others?

An update for Teensy LC and 3.2 to add the 15 second button press and a couple other minor features is definitely on my todo list.

But he says he's got a Teensy 3.1. PJRC discontinued 3.1 years ago, and 3.0 was discontinued too, quite some time after 3.1. We're not ever going to publish any updates for the 3.0 & 3.1 boards. The 15 second button press-to-erase will never come to those older boards. But they will continue to be supported by Teensyduino for the foreseeable future.

Those older boards relied on a different anti-bricking scheme. The bootloader would silently intercept the incoming data and simply refuse to write to the FSEC byte. This was changed in 3.2 (and all boards now using the MKL02 chip for their bootloader) to instead initialize FSEC with a default value and then allow writes. The result is you can do more with the new boards, and they're (hopefully) more robust against bricking... unless you both erase and write the flash yourself.
 
Status
Not open for further replies.
Back
Top