BDM and FLASH security (MC9S12C32)

[zocy]

I'm developing a BDM based FLASH program utility; it works fine with my HC12 CPUs, but I encountered some problems when trying to support the HCS12C32.

After resetting the CPU to active BDM mode (BDM enabled and active), I get 3 different options that depend on FLASH array condition:

1) FLASH is empty and unsecured, that is, 0xFF0F is programmed to 0xFE. BDM status register BDMSTS reads 0xC0 (ENBDM = 1, BDMACT = 1, UNSEC = 0). I can access FLASH state machine and mass erase and erase verify functions work fine. I can execute code from RAM.

2) FLASH is empty and not unsecured, that is, 0xFF0F is left in unprogrammed state (0xFF). BDM status register BDMSTS reads 0xC2 (ENBDM = 1, BDMACT = 1, UNSEC = 1). I can access FLASH state machine and mass erase and erase verify functions work fine. I CANNOT execute code from RAM.

In both cases 1) an 2) FLASH programming using BDM commands works fine ONLY on lower FLASH page (0x3E). On higher FLASH page all addresses get shifted left for one bit, that is, when trying to program 0xFF0E location, location 0xFE1C gets programmed instead. I'm puzzled.

3) FLASH is not empty and not unsecured (some words programmed, 0xFF0F left unprogrammed). All BDM reads using _BD_ commands return zeros and I can't really do anything. I'm puzzled even more.

The FCLKDIV register was set after each reset to 41 (0x29). The value is calculated using the fig. 4-1 determination procedure. I use 8 MHz crystal and PLL is not configured, so oscillator frequency is 8 MHz and bus frequency is 4 MHz, right?

For my projects I use iSystem IC3000 emulator and it has no problems interfacing to C32. It can program, secure, and unsecure FLASH with no trouble at all, so I guess there are no hardware related issues.

So, what did I miss? Any hints?

Thanks for being patient reading all this

[peg]

Hi zocy,

Well I'm confused as to why you are confused!

The observations you have noted in 1) to 3) are what I would expect (Except the address shift thing)

When security is enabled you can only mass erase.

What is different to what you have observed with the previous devices?

Regards

Peg

[zocy]

Hi Peg,

thanks for being confused with me, I'm so glad I'm not alone :smileyhappy: Well...

The UNSEC bit. Datasheet says "UNSEC is read as 1 ... when the device is secured and fully erased, else it is 0" and then later on in the bit description "0 System is in a secured mode, 1 System is in a unsecured mode". 1 = secured, 1 = unsecured, so which one should I pick?

Let's say my chip ends up in mode 3) (BDM reads zeros). How can I perform e.g. a mass erase?

Even if I forget about the first two, the address shift thing alone is frustrating enough, since I just can't program 0xFF0E to unsecure my FLASH. Why only the lower page gets programmed OK? Any idea what I might be doing wrong?

With respect to previous devices the BDM module has changed; there are some new features such as more flexible clock sources, some new commands, some timings have changed... The most important difference as I see it is the security feature, which proved to be very effective indeed.

Regards
Zoran

[kef]

Regarding 2) (all the flash and security byte is erased) and 3) (secured). You can't execute code from RAM. But in order to mass erase (if secured) or to program (all is erased) you don't have to run any code in RAM. Using hardware BDM commands you can write directly to flash/eeprom module registers and make flash module erasing/programming. FCLKDIV, FCMD, etc registers are readable and writeable directly from your BDM pod.

[zocy]

I haven't tried executing code from RAM because the cpu was locked. I just put too much focus on my BDM pod reading zeros from BDMSTS and wanted to solve a problem that never really existed. Well, thanks for giving me a kick :smileyhappy: I finally managed to erase FLASH using hardware BDM commands the same way as in 1) and 2). Still have the address shift thing...