Vector table redirection and block protection issue(unable to write into NVPROT & NVOPT)

[BASAV]

Hi! I am working with MC9S08DZ60 controller. compiled with cosmic compiler and am using Trace32 debugger. I have divided my project into BOOT and Application. boot code resides in the flash from 0x8200 -> 0xFFFF. Application resides in the flash at 0x1900. and have built two .elf files separately for debugging. My issue is, when I use flash block protection feature in the DZ60, which is NVPROT register needs to be programmed with the value, the amount of flash needs to be protected(0xEA). After exit from reset, the high page register FPROT is loaded with the contents of the NVPROT location. and am trying to redirect the vector table by writing to NVOPT. I am unable to write to these NVPROT and NVOPT registers.except these location am able to program every byte of my .s19 file. This is a snippet of my S19 file: S11FE2403536372D303048573030323631343339372D3030000000000000000093 S106FFBDEAFFBF95 S123FFC0D4E1D4E189B688CA8B078BEBC137D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1C5 S123FFE0D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E1D4E182FFE1 S123D4F98789879BC61825A5102705A610C71825957F2056A655C7180048C71800C61825B1 Am i missing somthing? If you guys can provide some solution, it's greatly helpful. Thanks in advance.

[kef]

NVPROT and NVOPT are part of flash and you can't just write them, they both must be programmed like other bytes in flash. Once some part of flash is write protected (NVPROT != 0xFF), you won't be able to reprogram NVOPT and NVPROT from your code.

In my opinion flash write protection and vector redirection is wrong on S08D. Why FPROT register (don't mix with NVPROT) is read only? On more recent S12(X)'s FPROT is writeable, but only towards protecting more bytes. You can't unprotect what is already protected, only write FPROT so that you protect more bytes. Vector redirection is almost perfect on S12X. There's dedicated vector base register. You can move vector table to any 0xXX00 starting address.

On S08D vector redirection is really weird:

- bootloader always should be write protected. While in bootloader, default vectors should be at default 0xFFXX addresses.

- when control is to be passed to application, only then vector redirection should be made enabled. And this should be not coupled to flash write protected area. The rest of flash, or the rest of flash minus EEPROM emulation area should be made all write protected as soon as we jump to application. Of course we do not want vectors redirected to below all the flash.

[BASAV]

I am not programming NVOPT and NVPROT registers from my code.am trying to flash them through Trace-32 debugger.except these registers, rest of the flash is getting programmed. don't understand why??

[BASAV]

Hi! Kef, My actual requirement is ... I have loaded a boot file into controller by using debugger. now i want to update the boot (without using a debugger) by sending a file like app. so could you suggest me some kind of solution...

[BASAV]

any has any ideas??

[Juls]

well in theory you can erease or reprogram the bootloader from the bootloader itself

that part of memory should be secure and require a debugger to reflash

those unit are in the field? or still in developpement looking for the right code to make it possible?

[BASAV]

units are in the field. which doesn't have a debugger support.

[rocco]

Hi Basav,

I finally figured out what you were asking.

If I understand the DZ family, which I don't use (so someone correct me if there is another way), then this is what you need to do:

If the bootloader is in protected flash, then the only way to replace it is to do a mass-erase of the entire flash. That needs to be done from ram. The steps would be:

1) You need to create a new application that the old bootloader is able to load into the flash. That application would contain an image of the new bootloader, plus additional programming support firmware.

2) That application, when it runs, would copy the programming support firmware and the new bootloader image into ram.

3) The programming firmware, running in ram, would mass-erase the flash.

4) The programming firmware, still running in ram, would copy and program the new bootloader into flash.

5) The programming firmware would then set the appropriate protection bits.

6) The new bootloader would then be started in the usual way, whatever that is, to load new application firmware.

Does that sound right?

[BASAV]

Hi! Rocco,

Thank you very much great effort.

there are some more hurdles in this design.

1. Mass erase is not possible when block protection is enabled. 
look at the following phase which is from DZ60 Data sheet:

"Trying to alter data in any protected area will result in a protection violation error and the FPVIOL flag
will be set in the FSTAT register. Mass erase is not possible if any one of the sectors is protected."

2.Protected flash cann't be unprotected from application code.

look at the following phase which is from DZ60 Data sheet:
"FPROT can be written only with background
debug commands, not from application software."

3. Remember my boot code is 19K, but the DZ60 controller has got only 4k of RAM.

4. The main problem is with vector table, we can't overwrite the table from application software.

and final thing, if we can erase a protected flash from RAM, then what is the point of protection?

[rocco]

Hi BASAV,

---

BASAV wrote:

1. Mass erase is not possible when block protection is enabled. look at the following phase which is from DZ60 Data sheet: "Trying to alter data in any protected area will result in a protection violation error and the FPVIOL flag will be set in the FSTAT register. Mass erase is not possible if any one of the sectors is protected."

I see that now. That must be a newer feature than on the chips I use. Or maybe I misunderstood. I don't use block protection, as my boot-loader has it's own block-protection scheme to protect itself.

2.Protected flash can't be unprotected from application code. look at the following phase which is from DZ60 Data sheet: "FPROT can be written only with background debug commands, not from application software."

I think that has always been true that you can't un-do block protection. Otherwise, it isn't really protecting.

3. Remember my boot code is 19K, but the DZ60 controller has got only 4k of RAM.

Wow! 19k for boot? I did not know that. My bootloader is less than 2k, and it includes encryption. Is your's written in C?

4. The main problem is with vector table, we can't overwrite the table from application software.

Yes. I see that. In other S08 members, you could mass-erase and end up with the original (new) configuration again. My bootloader always overwrites the vector table, except for the RESET vector (it's protected). But, again, I don't use block protection.

and final thing, if we can erase a protected flash from RAM, then what is the point of protection?

The point (if it worked) would be that no one could steal your code, because the only way to gain access to the chip would be to erase everything that was there. So you could install new code, but you could not access the old code.

---

So it looks like the bootloader cannot be updated in the field without some form of debugger attached. Sorry.

[BASAV]

Thanx for your insightful points.