DisengageSecurity & FlashBlock

[NoxArt]

Hi,

I'd like to ask... we have a school project and I'm rather webdeveloper so please pardon my great noobness

We are to create subroutines for manipulating with flash (erase, program...). The ones I have issues with are

1) Disengage flash security

So I follow the 3-step way from manual page 58. However it says that I can write the code only from RAM, but it seems to me the only instruction, that can write to 16bit address ($FFB0-7) is STA/STHX ... which I'd guess to be located among D/H-page registers -> so it seems impossible to solve it

2) Flash Block protection

"FPROT cannot be changed directly from application software" + "protected, NVPROT is itself protected and cannot be
altered by the application software"

It again seems impossible ... there's a background regime mentioned, but I thought it's only operated by debug soft and not the program I load into flash

(the task description does not state any more details/hints)

The installed version in school is CW 5.9.0, project is Full Chip Simulation, MC9S08JM60

Could anyone point me in the right direction?

Thank you very much!

[kef]

1) All 3 steps, setting KEYACC, writing to NVBACKKEY locations and clearing KEYACC should be done from routine in flash. Of course it's possible. I have no idea what is D/H-page.

2) Right, without BDM debugger you can't unprotect what is write protected.

[NoxArt]

Thank you for response! and sorry for not being totally clear

1) I mean - from what I understand the manual says that when I issue intruction to move the key# (the user-entered to be compared) to NVBACKKEY#, key# has to be placed inside RAM or Flash.

Now NVBACKKEY# afaik resides in 16bit address AND the only instruction storing to 16bit address is STA/STHX, but it takes only from register, not RAM or Flash...

By D/H-page I meant Direct-page registers, High-page registers

2) So it is not possible to create a subroutine altering  the last unprotected page? Hmm... maybe I misunderstood the task, unless we should write it's impossible, but it's less likely

[kef]

1) No, #key source can't reside in flash. Flash is not readable while KEYACC is set.

I don't undested what's the problem with STA/STHX. S08 CPU is powerful enough to copy 8 bytes from one place to another :smileyhappy:. Both, from D to H  and from H to D.

2) Yes, it is not possible to create such routine.

[NoxArt]

 :-) yes, it's not about performance, it's solely about this sentence from manual:

(so not performance but security/protocol? thing)

"The security key can be written only from secure memory (either RAM or flash)"

...and as far as I know STA/STHX takes from registers, not RAM/flash

but it's of course more than likely I am incorrect in whatever I posted

[kef · Accepted solution]

Again, flash is not readable while KEYACC is set. The only way to backdoor unsecure is to copy unsecure routine to RAM and call its copy in RAM.

[NoxArt]

Oh wait - so the sentence speak about the address of the CODE that is executing the insertion of key and not of DATA (key) itself? Ok, it seems solvable now

Thank you for your time and effort!

[kef]

Not only code, but also key to compare should be in RAM before calling unsecure routine in RAM. Setting KEYACC will "break" all your flash memory. That means CPU couldn't execute code from flash, also could read backdoor key from flash. Do you have interrupts enabled? - Disable them, because CPU couldn't read interrupt vectors from flash and jump to ISR routines in flash.

[NoxArt]

Thanks, ok.... as long as one is allowed to use STA (which does not seem 100% sure according to sentence I posted, but according to your response it is so I'll believe you) it's ok
(allegedly it's not possible to use STHX "STHX must not be used for these writes because these writes cannot be done
on adjacent bus cycles." but it's not a problem since the data get easily be written in 8bits)

I'm really grateful for your responses