adammunich
Member
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.
(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?
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: