KillerLink
New member
Hello dear Forum!
Im currently in the process of writting a bare-metal environment for the teensy 3.6 (learning purposes, no specific use case so far), meaning that i do not use any existing libraries, but instead writting them on my own, with datasheets.
A few questions regarding have arosen to me, which are as follows:
1)
Flash Security: As far as i have read and understood the Documentation, there is a memory region, located at 0x0000_0400 plus the 16 following bytes, which is used to initialize certain hardware register. One of them, called FSEC, is capable of a) disable mass flash erase and b) disable debugging access. I understood that this might make it impossible to reprogramm the chip if configuration is done wrong. I have read the according documentation, and prepared my image to NOT lock down the chip (because im developing it, and want to continue reprogramming it
)
My questions regarding this are:
A) The FSEC byte contains 4 boolean choices, but each of those is encoded as 2 bits. I'd guess since (in 3 of 4 choices) 3 options are mapped to (e.g.: 0b00,0b01,0b11) "boolean false" and 1 (e.g.: 0b10) is mapped to "boolean true" it might be to make it harder to accidentaly set it to something undesired? Can someone explain the technical background / reason for this?
B) As described in the paragraph above, three choices (e.g.: 0b00, 0b01, 0b11) might map to the same decision. For one of the choices the datasheet says "preferred", but does not seem to explain why? (Reference: NXP Application Note AN4507.pdf, page 2, field KEYEN, preferred state 0b01)
C) I am a little paranoid about accidently locking my chip. As far as i understood there is absolutly NO way back (for normal human beeings) from disabling mass erase & disabling debug access? Do I understand correctly that as far as one of both (mass erase, debug access) is available the chip can be recovered? As a safeguard i would like to enable the Backdoor Access Key by default with a simple key such as 0x0123456789ABCDEF, even if i do not enable security ( == disabling debug access), so IF i ever accidentaly enable security i could still get debug access with that key to reprogramm the chip? Is this a reasonable approach?
D) I understood that reprogramming the flash works in pages. If my hex file does not contain any directions/data for the page starting at 0x0000_0400 and ending at 0x0000_04FF, this section should not be updated and left untouched? That is, will the halfkay loader erase the entire flash or only the pages that it NEEDS to rewrite according to the hex file? Is it better to try to avoid reprogramming this memory area or trying to always contain a non-lock-down configuration for this area?
E) I read that the halfkay bootloader has special handling for this case (See link [1]). It is indicated, but not entirely clear to me for teensy 3.6, that the halfkay loader actually will not allow me to writte a value to 0x0000_040C that would disable the mass erase command, and therefore would prevent me from locking myself out. Is this correct and can i reasonably rely on that as safety net, as long is use the halfkay loader (cli version) to programm?
Reference [1] https://forum.pjrc.com/threads/3442...e-flash-memory?p=104158&viewfull=1#post104158
best regards
thanks in advance
Im currently in the process of writting a bare-metal environment for the teensy 3.6 (learning purposes, no specific use case so far), meaning that i do not use any existing libraries, but instead writting them on my own, with datasheets.
A few questions regarding have arosen to me, which are as follows:
1)
Flash Security: As far as i have read and understood the Documentation, there is a memory region, located at 0x0000_0400 plus the 16 following bytes, which is used to initialize certain hardware register. One of them, called FSEC, is capable of a) disable mass flash erase and b) disable debugging access. I understood that this might make it impossible to reprogramm the chip if configuration is done wrong. I have read the according documentation, and prepared my image to NOT lock down the chip (because im developing it, and want to continue reprogramming it
)My questions regarding this are:
A) The FSEC byte contains 4 boolean choices, but each of those is encoded as 2 bits. I'd guess since (in 3 of 4 choices) 3 options are mapped to (e.g.: 0b00,0b01,0b11) "boolean false" and 1 (e.g.: 0b10) is mapped to "boolean true" it might be to make it harder to accidentaly set it to something undesired? Can someone explain the technical background / reason for this?
B) As described in the paragraph above, three choices (e.g.: 0b00, 0b01, 0b11) might map to the same decision. For one of the choices the datasheet says "preferred", but does not seem to explain why? (Reference: NXP Application Note AN4507.pdf, page 2, field KEYEN, preferred state 0b01)
C) I am a little paranoid about accidently locking my chip. As far as i understood there is absolutly NO way back (for normal human beeings) from disabling mass erase & disabling debug access? Do I understand correctly that as far as one of both (mass erase, debug access) is available the chip can be recovered? As a safeguard i would like to enable the Backdoor Access Key by default with a simple key such as 0x0123456789ABCDEF, even if i do not enable security ( == disabling debug access), so IF i ever accidentaly enable security i could still get debug access with that key to reprogramm the chip? Is this a reasonable approach?
D) I understood that reprogramming the flash works in pages. If my hex file does not contain any directions/data for the page starting at 0x0000_0400 and ending at 0x0000_04FF, this section should not be updated and left untouched? That is, will the halfkay loader erase the entire flash or only the pages that it NEEDS to rewrite according to the hex file? Is it better to try to avoid reprogramming this memory area or trying to always contain a non-lock-down configuration for this area?
E) I read that the halfkay bootloader has special handling for this case (See link [1]). It is indicated, but not entirely clear to me for teensy 3.6, that the halfkay loader actually will not allow me to writte a value to 0x0000_040C that would disable the mass erase command, and therefore would prevent me from locking myself out. Is this correct and can i reasonably rely on that as safety net, as long is use the halfkay loader (cli version) to programm?
Reference [1] https://forum.pjrc.com/threads/3442...e-flash-memory?p=104158&viewfull=1#post104158
best regards
thanks in advance
