Need hel pwith a bootloader

[stevech]

This is what I understand....
Yes, the Mini54 uses the K20's single wire debug (SWD) pins (2) to copy K20 M4 code from the Mini54 to RAM in the K20, then tells the K20 to run that. The code is a bootloader (Halfkay) that uses only USB.

A nice change to preclude bricking would be if the Mini54 finds a 0xFF in the 0x40C location, it then reads a jumper IO pin on the Mini54 package to decide which kind of K20 is in place.

 

[uTasker]

The meaning of the byte in Flash at 0x40c is documented in the FTFL_FSEC field description of the K20 user's manual.
It has nothing to do with the Teensy or the Teensy loader, but is defined by the Kinetis device.

Basically this value is read by the K20 when it boots up and controls its subsequent security setting - it doesn't give any information about the chip that is being used.

If the last two bits are not bxxxxxx10 the Kinetis is secure. This means that the operations possible over the SWD/JTAG/EzPort are limited to commanding a mass erase (at the most). It is neither possible to read code from the device nor use the debug interface for actual debugging.
If the bits 4 and 5 are bxx10xxxx it means that the Kinetis will also not allow a mass erase to be performed

If the location were to be programmed with
bxx10xx00
bxx10xx01 or
bxx10xx10
it would completely disable all operations over the SWD/JTAG/EzPort interfaces.

The code that is programmed in the device can still operate and erase/reprogram, so if a boot loader is in place it still can update code and it can also perform erase operations - it can also remove security (the purpose of the command that may have caused other difficulties together with the mini54tan).
If however there is no code loaded that operates, and/or doesn't allow programing or deleting, the Kinetis is effectively stuck in this state forever - if the code doesn't even run this is a real "Bricked" board.

The question is whether the mini54tan can handle the "standard" secured state (0xff) or not. It won't be reading the 0x40c byte to determine what board it is on, and won't be able to read, write, program the K20 at all until it performs the standard unsecure sequence which is:
- command a mass erase to temporarily allow modifying the security
- write the security setting to non-secure
- program the byte at 0x40c to 0xfe (only necessary when not programming new code anyway)
If it doesn't do this it means that a 'standard' secured K20 would aready behave like a bricked board, although this is not the case. Any debugger or EzPort programmer will be able to unsecure it if it can be connected to the pins and the MINI54TAN held in reset state.

Regards

Mark

 

[stevech]

The K20's factory bootloader isn't present, so 0x40C is read by some K20 hardware mechanism when the Mini54 resets the K20?

Paul warns that if 0x40 is altered, the Teensy is likely bricked unless one disables the Mini54 and has a way to write some value into 0x40. This is specific to Teensy as you say.