Want to reconfigure Teensy3 FlexRam/FlexNVM for EEPROM and data flash

[froeber]

Hi all, I'm trying to figure out how to switch my Teensy3 from the "standard" EEPROM setup Paul provides to a custom one. The standard setup is that the 2KB Flexram and 32KB of FlexNVM are used together to provide 2KB of EEPROM. I wanted to switch to have 8KB of Data Flash and then use the other 24KB of data flash as backup for 2KB of EEPROM. I got all the code written to do this. The initialization involved reading the Data IFR "resource" to find out the previous program partition setup and then reprogramming it as needed. Seemed pretty reasonable to do (like I do a lot I looked at code from the Freescale MQX RTOS that has support for huge amounts of features on the Teensy processor).

I went to run it and hit the problem that you can't change the program partitioning unless it has been erased first. So, to change the partitioning you need to do a full chip erase prior to loading running your new program. And that would be fine if I could just figure out how to do a full flash erase. From what I've seen on the forum Teensy loader used to do a full chip erase since that was "safest". But that post was over a year ago. I think the loader now does something different and doesn't erase the whole chip. That's good if you are doing "normal" app development and want to have EEPROM data saved across reloads (a nice feature). But it's not clear how you can ever change the setup without doing something like loading a special program that triggered an "erase all" -- killing the board. And then using the loader again to load the real program that would then be able to set a new configuration since there was a clean slate to work with -- at least I'm hoping that would be the case.

So is there any easier way anybody knows of to erase everything so you could make partitioning changes? I'm guessing this is a Paul question?

Thanks for any suggestions! Fred

[PaulStoffregen]

While uploading, the configuration is changed to be a RAM buffer only. So the first time your sketch starts running, the FlexNVM should be configured for RAM and can be changed to another setting.

The code in hardware/teensy/cores/teensy3/eeprom.c automatically reconfigures the FlexNVM for 2K of EEPROM the first time you try to use it. You'll need to edit this code, or make your own copy and be sure your copy gets called before anything tries to use the eeprom functions.

Here's the code.

void eeprom_initialize(void)
{
        uint32_t count=0;
        uint16_t do_flash_cmd[] = {
                0xf06f, 0x037f, 0x7003, 0x7803,
                0xf013, 0x0f80, 0xd0fb, 0x4770};
        uint8_t status;

        if (FTFL_FCNFG & FTFL_FCNFG_RAMRDY) {
                // FlexRAM is configured as traditional RAM
                // We need to reconfigure for EEPROM usage
                FTFL_FCCOB0 = 0x80; // PGMPART = Program Partition Command
                FTFL_FCCOB4 = EEESIZE; // EEPROM Size
                FTFL_FCCOB5 = 0x03; // 0K for Dataflash, 32K for EEPROM backup
                __disable_irq();
                // do_flash_cmd() must execute from RAM.  Luckily the C syntax is simple...
                (*((void (*)(volatile uint8_t *))((uint32_t)do_flash_cmd | 1)))(&FTFL_FSTAT);
                __enable_irq();
                status = FTFL_FSTAT;
                if (status & 0x70) {
                        FTFL_FSTAT = (status & 0x70);
                        return; // error
                }
        }
        // wait for eeprom to become ready (is this really necessary?)
        while (!(FTFL_FCNFG & FTFL_FCNFG_EEERDY)) {
                if (++count > 20000) break;
        }
}

Those 8 numbers are a tiny function that runs from RAM. Here's that code:

void do_flash_cmd(volatile uint8_t *fstat)
{
        *fstat = 0x80;
        while ((*fstat & 0x80) == 0) ; // wait
}
00000000 <do_flash_cmd>:
   0:   f06f 037f       mvn.w   r3, #127        ; 0x7f
   4:   7003            strb    r3, [r0, #0]
   6:   7803            ldrb    r3, [r0, #0]
   8:   f013 0f80       tst.w   r3, #128        ; 0x80
   c:   d0fb            beq.n   6 <do_flash_cmd+0x6>
   e:   4770            bx      lr

Really, the only tricky part here is the function needs to run from RAM, and the C syntax to cast a pointer to an array into a callable function pointer is a bit ugly. Hopefully this example gives you everything you need. Just change the FTFL_FCCOB5 register for your desired data flash partitioning. You might also decrease EEESIZE, since you'll be using less memory for the wear leveling.

[froeber]

While uploading, the configuration is changed to be a RAM buffer only. So the first time your sketch starts running, the FlexNVM should be configured for RAM and can be changed to another setting.

Paul, Thanks for the info! So, the upload process still uses the "erase all blocks" command. And then the next time my program starts the standard eeprom_init code comes in and sets things up for 2KB of EEPROM. So I can make sure my init routine for data flash setup runs before eeprom_init and I'll be able to do the setup the way I want.

Only one thing is still confusing me. Our Teensy application uses EEPROM to store persistent data. When I reload a new program the EEPROM data doesn't go away. And that confuses me. Because if the loader erases all blocks doesn't it erase the EEPROM too? So does the loader save and then restore EEPROM data? I remember from a post over a year ago you saying you expected to do that at some point in the future (from that point over a year ago). Have you actually fixed the code to save and restore EEPROM data.

Thanks again for any clarification. I really like the fact that you provide such timely and useful advice/inputs. Fred

[PaulStoffregen]

Because if the loader erases all blocks doesn't it erase the EEPROM too?

No.

The original version erased everything. The latest version only erases all the flash blocks and resets the flexnvm to RAM-only. It leaves the 32k of data flash untouched. If you reprogram the flexnvm partition to eeprom use, as the eeprom initialization code does, the previously written eeprom data is preserved.

[froeber]

Hey Paul, Right on! Excellent details to know and sounds like a great solution. Thanks for the info! I'm now "good to go" on this issue.

[froeber]

Paul, I guess I'm still a bit confused about the configuration details at startup. I have code that replaces your eeprom.c code because I want a configuration with EEPROM and some Flex NVM for Flash data storage. I'm using release 1.16 of Teensyduino with a Teensy3. I find that if I first run a sketch that just triggers an ERASE_ALL_BLOCKS flash controller command and then load my real application that checks FTFL_FCNFG & FTFL_FCNFG_RAMRDY to see if FlexRAM is set up for pure RAM, the code does detect that setup. My application then partitions the the FlexRAM/FlexNVM the way I want it with a mix of EEPROM and data flash.

However, if I then reload my same application using your loader then my code doesn't detect that the setup is pure RAM the way it was after the ERASE_ALL_BLOCKS. In fact I use a READ_RESOURCE command to read the data IFR configuration and the partition configuration remains set up the way I had it with the partitioning I want. Thus I think your loader now doesn't "reset the flexnvm to RAM-only" as you indicate above. I'm guessing that the loader doesn't change the partition configuration at all so if someone wants to use two different applications on your board that have different EEPROM/data flash configurations they will have to do what I did of running a small sketch that just does an ERASE_ALL_BLOCKS so that they can then run their "real" sketch to configure the partitions the way they want.

It's ok that things work this way. It does mean an extra step if you ever want to change the partitioning. I really just want to get some feeling if you agree with my assessment of how things work. Also, I think things have to work this way because as far as I can tell there is no way to change partitioning without first doing an ERASE_ALL_BLOCKS which, of course, loses any data you may have saved in EEPROM. Thus, your loader now allows you to reload your sketch without losing the EEPROM (and data flash if so configured). Which is a good thing.
Fred

[tigercat]

Yep, froeber is right. And now I've got myself a bricked Teensy 3.1. It sounded like froeber said simply do a ERASE_ALL_BLOCKS like this...

    uint16_t do_flash_cmd[] = { 0xf06f, 0x037f, 0x7003, 0x7803, 0xf013, 0x0f80, 0xd0fb, 0x4770 };
  __disable_irq();
  FTFL_FSTAT = FTFL_FSTAT_RDCOLERR | FTFL_FSTAT_ACCERR | FTFL_FSTAT_FPVIOL;
  FTFL_FCCOB0 = 0x44;
  (*((void (*)(volatile uint8_t *))((uint32_t)do_flash_cmd | 1)))(&FTFL_FSTAT);
  __enable_irq();

which runs, and it probably erases the data flash IFR too (which is what is needed to repartition the EEPROM), but it's hard to tell because in the process the Teensy is bricked. So all I can say is don't do this, and now how the froeber do I unbrick a Teensy 3.1???

[stevech]

Are the two pins for SWD (clock, data) accessable, so you can use a cheap SWD debug pod to recover?

PJRC has some means to do the above, I'd think.

[tigercat]

Are the two pins for SWD (clock, data) accessable, so you can use a cheap SWD debug pod to recover?

PJRC has some means to do the above, I'd think.

Good idea, but the SWD pins are connected to the MINI54 controller chip, which loads the USB bootloader into the MK20. Apparently there are hardware config parameters in the middle of the MK20 flash, including an important mystery value at 0x41C, that get wiped out by an Erase All Blocks command. So if the MINI54 isn't reprogramming these config values to a safe value, then the MK20 won't boot and it won't be recognized as a USB device, which is what's happening. And since I can't reprogram the MINI54 to fix this, it looks like the end for my bricked Teensy.

Perhaps a clever program that runs in ram could erase all flash and reprogram the config values in one step, which should leave the MK20 in working state. That would then allow the EEPROM partitioning to be changed. But for now I'm just going to consider the Teensyduino EEPROM size to be a permanent setting that can only be set once.

Of course an option to simply erase the FlexNVM area when uploading, like the old loader did, would be the best solution.

[Frank B]

I wrote my own bootloader.. it's possible :-)
But it does not delete the whole flash, only the needed sectors, and it verifies this magic 0xfe at 0x04xx... before doing anything..

[stevech]

can you use a jumper to disable the Mini54 and let the SWD pins be used by a debugger pod? The pins might float if you hold the Mini54 in reset with a jumper.

[tigercat]

can you use a jumper to disable the Mini54 and let the SWD pins be used by a debugger pod? The pins might float if you hold the Mini54 in reset with a jumper.

Yes, the SWD traces can be jumpered in and the board eventually restored, but that's another project. As an Arduino type part this is a fail because there is no easy recovery available, so as the Teensy software developer recommends I'm just going to buy some spare Teensy 3.1 boards and not fool with potentially dangerous commands.

[stevech]

But when PJRC gets a "virgin" K20 CPU and it's already soldered onto the board, they must have some way to write that magic location in the flash!

[froeber]

Good idea, but the SWD pins are connected to the MINI54 controller chip, which loads the USB bootloader into the MK20. Apparently there are hardware config parameters in the middle of the MK20 flash, including an important mystery value at 0x41C, that get wiped out by an Erase All Blocks command. So if the MINI54 isn't reprogramming these config values to a safe value, then the MK20 won't boot and it won't be recognized as a USB device, which is what's happening. And since I can't reprogram the MINI54 to fix this, it looks like the end for my bricked Teensy.

Perhaps a clever program that runs in ram could erase all flash and reprogram the config values in one step, which should leave the MK20 in working state. That would then allow the EEPROM partitioning to be changed. But for now I'm just going to consider the Teensyduino EEPROM size to be a permanent setting that can only be set once.

Of course an option to simply erase the FlexNVM area when uploading, like the old loader did, would be the best solution.

Hey @tigercat, When I first was experimenting with this a while ago Paul had a different version of his loader running in the MK54 chip. That version used to do its own "erase all" of the main processor chip. As you found out, an "erase all" erased all the FLASH and NVRAM and FLEXRAM and Data IFR. This meant it also erased the Flash config block at 0x400-0x40f to all 0xff. Section 28.3.1 of the Rev 2 version of the MK20DX128VLH5 reference manual that I use (from Feb 2012) explains that 0x40C is the FSEC field. Setting it to 0xFF did enable flash security which means the external debug interface can only execute an erase all.

Note, with Paul's Teensy design the MIN54 doesn't load a USB loader into the processor. It executes a USB loader program that takes over the USB BUS and manipulates the processor using the debug interface to stuff a new program into it. And I do believe that at some point along the way Paul did change how the MIN54 loader worked such that it doesn't use erase all any more. But I know it also checks when downloading an image to make sure that the value programmed into 0x40c doesn't lock security.

Even though what you tried with running a program that does an erase all is what I used to do last year with the Teensy, back then it worked fine. Now I think doing an "erase all" from your program does brick things. Sorry for that. Most of what I am doing now is with bare processors with no MIN54 using a PE Micro Multilink JTAG programmer to stuff the program in or using my own USB loader running on the Teensy processor itself. I could never figure a way to try JTAG programming with the Teensy board itself though without seriously hacking the actual circuit board.

I wonder if there is some different MIN54 loader (ie like the old version) that you might get from Paul that would cause the MIN54 to go back to using an erase all to override the security lock and reprogram a new image into a locked board?
Fred

[tigercat]

Hey @tigercat, When I first was experimenting with this a while ago Paul had a different version of his loader running in the MK54 chip. That version used to do its own "erase all" of the main processor chip. As you found out, an "erase all" erased all the FLASH and NVRAM and FLEXRAM and Data IFR. This meant it also erased the Flash config block at 0x400-0x40f to all 0xff. Section 28.3.1 of the Rev 2 version of the MK20DX128VLH5 reference manual that I use (from Feb 2012) explains that 0x40C is the FSEC field. Setting it to 0xFF did enable flash security which means the external debug interface can only execute an erase all.

Note, with Paul's Teensy design the MIN54 doesn't load a USB loader into the processor. It executes a USB loader program that takes over the USB BUS and manipulates the processor using the debug interface to stuff a new program into it. And I do believe that at some point along the way Paul did change how the MIN54 loader worked such that it doesn't use erase all any more. But I know it also checks when downloading an image to make sure that the value programmed into 0x40c doesn't lock security.

Even though what you tried with running a program that does an erase all is what I used to do last year with the Teensy, back then it worked fine. Now I think doing an "erase all" from your program does brick things. Sorry for that. Most of what I am doing now is with bare processors with no MIN54 using a PE Micro Multilink JTAG programmer to stuff the program in or using my own USB loader running on the Teensy processor itself. I could never figure a way to try JTAG programming with the Teensy board itself though without seriously hacking the actual circuit board.

I wonder if there is some different MIN54 loader (ie like the old version) that you might get from Paul that would cause the MIN54 to go back to using an erase all to override the security lock and reprogram a new image into a locked board?
Fred

Thanks Fred, that fills in some of the pieces of this puzzle. Also AN4386 (http://cache.freescale.com/files/mic...n&fileExt=.pdf) explains the issues in good detail. Basically it needs a bulk erase at this point, which can only be done by a flash programmer or the MIN54.

There are pads on the Teensy board that are probably the MIN54 programming pins, so perhaps updating the loader wouldn't be as bad as hacking into the K20 directly. If I could get a loader hex file, I'd try it.

[tigercat]

Here's a detailed Teensy ERASE_ALL unbrick procedure using a J-Link EDU, with thanks to froeber for all the technical hints that were needed to figure this out...

Jumper the MINI54 reset signal to ground, which keeps it from interfering with the MK20 while we reprogram it. The MINI54 reset is on the bottom of the board; it's the unlabeled pad closest to the Teensy pin "1". Connect a jumper from this pad to Teensy pin GND or AGND.

Hook up the Teensy to the J-link as described in this article, except don't cut any traces: http://mcuoneclipse.com/2014/08/09/h...swd-debugging/ :

• Jlink pin 4 (ground) to Teensy GND pin.
• Jlink pin 19 (power) to Teensy Vin pin.
• Jlink pin 1 (VTref) to Teensy 3.3V pin.
• Jlink pin 15 (reset) to Teensy pad "R" on bottom of board.
• Jlink pin 9 (swclk) to Teensy MK20 chip pin 22.
• Jlink pin 7 (swdio) to Teensy MK20 chip pin 25.

An alternative to soldering the two tiny chip pins is to use a wedge clip: http://www.emulation.com/158/.

The Teensy will be powered by the J-Link, so do not plug it into USB for now.

Start J-Link Commander (I used V4.96a) and enter these commands:

J-Link> si 1
J-Link> power on
J-Link> device ?

A pop-up window will appear; select the MK20DX256xxx7 from the list. A pop-up message will appear saying the device is secure and asking if you want to erase it. Say yes.

J-Link> power off

Remove the jumper & hookup wires from the Teensy.

Hold the Teensy "reset" button while plugging it into USB socket, then release the button.

The Teensy board should be as good as new now, including the ability to set a new EEPROM configuration. The factory-programmed Teensy serial number (MAC) is not affected by this procedure.

[Frank B]

What is the advantage over an external SPI EPROM or flash?
I mean, ok, switching to SRAM can be easyly done, without any hack if one wants 2KB RAM more. Adding a SPI-Chip for EEPROM or Flash can be done in some minutes..
pls. give me a hint

"Want to reconfigure Teensy3 FlexRam/FlexNVM for EEPROM and data flash "

[tigercat]

What is the advantage over an external SPI EPROM or flash?
I mean, ok, switching to SRAM can be easyly done, without any hack if one wants 2KB RAM more. Adding a SPI-Chip for EEPROM or Flash can be done in some minutes..
pls. give me a hint

"Want to reconfigure Teensy3 FlexRam/FlexNVM for EEPROM and data flash "

The Teensy EEPROM works fine; the problem is that there is no published way to change the Teensy EEPROM configuration once it's been set. For production that's fine, but for experimentation and development it'd be nice to be able to reconfig the FlexRam/FlexNVM to different settings. So far the best answer is to tack on an emulator pod like the J-Link to bulk erase the K20 chip, after which the EEPROM (FlexRam/FlexNVM) config can be set to a new value just like it was a brand new Teensy board.

[NickViz]

The same story happened with me: https://forum.pjrc.com/threads/26693...ocks-Command-(
Paul generously replaced the board, but I guess the big red message - do not erase all memory with bulk erase - should be posted somewhere...

[tigercat]

The same story happened with me: https://forum.pjrc.com/threads/26693...ocks-Command-(
Paul generously replaced the board, but I guess the big red message - do not erase all memory with bulk erase - should be posted somewhere...

Yes, they should state that once you set the EEPROM it can't be changed. And the bootloader should have been designed so that it bulk erases the K20 when you hold down the button for 30 seconds. That would have made the Teensy board unbrickable, plus it would have allowed for easy reconfiguration of the EEPROM size.

[RedoX]

Hi everyone,

I unknowingly ran into the same problem (Never had the issue with Teensy3.0 before...) and after some trials, failures, and one (temporarily I hope) bricked Teensy3.1 managed to write some code to erase the EEPROM size setting so it can be reconfigured later.

Disclaimer:

This code is provided as is, with no warranty, expressed or implied.
I believe this code to be free of encumbrance, and offer it to the
public domain. I not liable for anything that results from your use of this
code. Please make sure you understand what you are doing before using it.

There are two folders:

- TsyNOPE: Dead simple program, meant to be flashed after the Erase steps.
Provided only for information as it has already been compiled and
included in TsyEraseALL (it's the p[] array stored at .ramtable0)

- TsyEraseALL: Potentially harmful app:
- Wait for a while, allowing time to connect a debugger
- Unlock the flash if necessary. I am not sure it would work though, since
it erases sector 1, so the next part may not work in that case. But it
should still be alright since the security word is re-written with
the correct value. The Mini54 should be able to flash the Teensy. Just
reflash this app to erase the flash.
- Erase the Flash ( ERASE ALL BLOCKS )
- Unsecure the chip ( set 0xFE at location 0x40C )
- Flash the TsyNOPE app. It allows the chip to be accessed/debugged using
SWD. Only erasing the flash and unsecuring the chip makes it impossible
to use SWD, but should allow the Mini54 to do its job.


How to use:

- Compile if you want (or use the provided .hex file)
make
- Flash
teensy-loader-cli -mmcu=mk20dx128 -w -v ./TsyEraseALL.hex

The LED lights up... Now you WAIT. Once it's finished, the LED should blink.
The blink rate should be slow (~500ms) if everything went well.

- Unplug the USB cable, replug.

- Try to load a script. EEPROM should be reconfigurable now.


It would be cool to have an easier solution though...

Thanks for the Teensys, awesome boards =)

Best regards,
RedoX

[RedoX]

to change the partitioning you need to do a full chip erase prior to loading running your new program

That's exactly what my code does: Full erase and reflash correct security settings (and flash a dumb app to be able to use SWD) But in order to do that, you have to run your program from RAM (since you erase the flash...). If you don't flash the correct security setting after the Full erase, the chip is secured upon reboot, the Mini54 can't access it and you can't use SWD Debug either (but recovering acces using a Mass erase is still possible using SWD, as tigercat pointed out) .

I think that on Teensy3.0 (and maybe early versions of 3.1), the Mini54 does a full chip erase, then loads a USB bootloader into the RAM of the K20x. On newer Teensy3.1, the behaviour has changed and only sectors of the Flash are erased, which means, if your code screws up the Security setting (at 0x40C), there is no way to recover that and to reflash the K20x (with the Mini54).

The behaviour on Tsy3.0 is more robust, since a Mass erase is almost always possible. The downside is that you loose the content of the EEPROM when you reflash the K20x.

One good option would be to change the bootloader/Mini54 code to merge the two behaviours, as tigercat suggested:
- Erase the flash sectors when doing a simple reset
- Do a mass erase when you keep the reset button pressed for a a long (30sec or more) time.

What I don't know is wether or not the bootloader (on the Mini54) can be upgraded...

[tigercat]

Thank you RedoX! Your TsyEraseALL works great (from the GUI too) and is a good workaround for reconfiguring the EEPROM. It will come in very handy for Teensy 3.1 experimentation.

Here is another piece (see attachment), it's a utility program to view & set the EEPROM configuration. It shows the current EEPROM configuration (if any) and allows the EEPROM configuration to easily be set to any valid size. The associated library includes a smarter EEPROM startup function, plus some simple bounds safe EEPROM access functions. Enjoy!

Teensy 3.1 EEPROM Partition Tool.zip

[pschuster]

Hi all,

I have created a custom Teensy board using the Mini54TAN before. Out of curiosity and if I don't have any Min54 left (I am living in Germany meaning it will take 3-4 weeks to get new Mini54s) I built my PCB with everything except the Mini54. I have a J-Link Edu and wanted to flash my application via SWD (I have these signals exposed on my custom PCB).

What I do is this (I am running on a Mac)

> ./JLinkExe -if SWD -device MK20DX256VLH7

SEGGER J-Link Commander V5.10s (Compiled Mar  9 2016 18:54:51)
DLL version V5.10s, compiled Mar  9 2016 18:54:45

Connecting to J-Link via USB...O.K.
Firmware: J-Link V9 compiled Mar  8 2016 11:12:56
Hardware version: V9.30
S/N: 269308445
License(s): FlashBP, GDB
OEM: SEGGER-EDU
Emulator has Trace capability
VTref = 3.325V


Type "connect" to establish a target connection, '?' for help
J-Link>connect
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>1000
Device "MK20DX256XXX7" selected.

Found SWD-DP with ID 0x2BA01477
Found SWD-DP with ID 0x2BA01477
Found Cortex-M4 r0p1, Little endian.
FPUnit: 6 code (BP) slots and 2 literal slots
CoreSight components:
ROMTbl 0 @ E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB000 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 003BB002 DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 002BB003 FPB
ROMTbl 0 [3]: FFF01000, CID: B105E00D, PID: 003BB001 ITM
ROMTbl 0 [4]: FFF41000, CID: B105900D, PID: 000BB9A1 TPIU
Cortex-M4 identified.

J-Link>erase
Erasing device (MK20DX256xxx7)...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Total time needed: 0.894s (Prepare: 0.105s, Compare: 0.000s, Erase: 0.780s, Program: 0.000s, Verify: 0.000s, Restore: 0.008s)
Erasing done.

J-Link>loadfile /Users/pschuster/Desktop/Blink.ino.hex 
Downloading file [/Users/pschuster/Desktop/Blink.ino.hex]...
Comparing flash   [100%] Done.
Erasing flash     [100%] Done.
Programming flash [100%] Done.
Verifying flash   [100%] Done.
J-Link: Flash download: Flash programming performed for 1 range (14336 bytes)
J-Link: Flash download: Total time needed: 0.505s (Prepare: 0.136s, Compare: 0.006s, Erase: 0.000s, Program: 0.312s, Verify: 0.000s, Restore: 0.048s)
O.K.

J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>g

Well, but the MK20 does not startup. I can see the Reset signal is HIGH, which shows that it's not empty (I think) and doing something. But I cannot see the crystal to start up using my oscilloscope.

Is there any configuration necessary for the MK20 besides the raw application? I.e. does the application at startup (first things it does in main) do all the setup (like start crystal commands) or are there any registers to set outside of the application?

I am asking you because you dived into these details in this topic and thought that you could perhaps help me.

Thanks in advance,
Phillip

[PaulStoffregen]

Is there any configuration necessary for the MK20 besides the raw application?

No extra configuration is necessary. However, the program-once memory will be blank, so the USB serial number will be 0xFFFFFFFF. Everything should still work.

Maybe try programming the known-good LED blink code?

http://www.pjrc.com/teensy/loader_vista.html