Illegal BP while Writing/Erasing Flash Memory on the 68HC12

[FallSe7en]

Hi everybody,

I'm having trouble writing/erasing to do the flash arrays on the MC68HC912DT128A. I have a couple of questions:

I am trying to use it as an extended EEPROM (writing data to it and reading data from it during normal operation). In the databook, it says that "Programming and erasing of Flash locations cannot be performed by code being executed from the Flash memory." Does that mean I cannot do what I want to do with the flash arrays?

I went ahead and coded up a test, but it's encountering an illegal breakpoint not long after I set the PGM bit (at the beginning of the 'program' operation). It seems to be time-dependent because the illegal breakpoint occurs even if I insert a few NOPs. I can't figure out why it might be happening though--any educated guesses or other things to test for/think about?

Thanks in advance!

[kef]

Thay tried to say in datasheet that flash array is not readable while it is being programmed. This further means that your flash programming routine should execute from RAM, EEPROM, external memory, another flash array, but not from the same array you are programming. CPU can't read program in flash, CPU hangs. On 912DT you have four 32k arrays. Don't forget to disable interrupts while programming nonpaged flash, since nonpaged 0x4000-0x7FFF and 0xC000-0xFFFF belong to the same flash array, and since flash is not readable while being programmed, vectors won't be readable by CPU as well.

[FallSe7en]

Hi, thanks for your reply. I have more questions though...

To my understanding, my code is located in the fourth 32k Flash array (that's where it goes by default, right?) and I am writing to paged Flash (I've set PPAGE to 0x00 to bring page 0 up in the window at $8000).

Because I am writing to nonpaged Flash, does that mean I don't have to disable interrupts? And because I am programming a paged flash array, can my vectors still be read by the CPU? If not, it does seem like the Modulus Down Counter Underflow interrupt is happening, but the CPU can't read the vector for it.

Thanks again!

[kef · Accepted solution]

It is not clear where your code is and what locations you are trying to reprogram.

• To my understanding, my code is located in the fourth 32k Flash array (that's where it goes by default, right?)

Defaults depend on your tools and how you are using them.

If all your code fits nonpaged addresses 0x4000-0x7FFF and 0xC000-0xFFFF, which belong to the same flash array, then programming PPAGEs 0-5 via PPAGE window should work without disabling interrupts and executing flash routines from RAM.

[FallSe7en]

EDIT: Yep, moving my code to $4000 worked. Thanks for your guidance!

Hi, thanks for all your help so far.

I took a look at my .map file and it actually has my code starting at $8000. I guess that's my problem right there--up until now I assumed the code would be in unpaged memory.

Now I'm trying to figure out how to move it out of that segment. I'm guessing I have to edit the .prm file but I haven't been able to find any documentation on how to change it yet...

[kef]

By default CW project wizard suggests banked memory model and most of the code goes to paged memory. You may recreate your project telling wizard you want small memory model.

It is easy to make some functions copied to RAM at runtime and execute them from there. Just two steps:

1) Put you RAM function between following two pragmas

#pragma CODE_SEG __NEAR_SEG RAMCODE
void RAMfoo(void)
{
}
#pragma CODE_SEG DEFAULT

2) Define placement for RAMCODE in prm file. Add into PLACEMENT-END block this line

    RAMCODE          INTO    RAM;

[FallSe7en]

Thanks for the tip. What does the '__NEAR_SEG' part of the first pragma line do?

[kef]

__NEAR_SEG makes functions from given segment called using BSR/JSR instructions and return using RTS. You can remove __NEAR_SEG, and functions in your RAM will be called using slower and bigger CALL instruction and return with RTC. Of corse this difference is eliminated using small memory model, in which all functions are called using BSR/JSR.

[FallSe7en]

Ah, I understand. Thanks.

Not sure if I should create a new thread for this or not, but I figured I'd try this first...

The illegal BP does not occur anymore, but it also looks like no data is actually being written. I wrote a little test program that writes a message to PPAGE 1 and then reads it back. Trouble is, it doesn't look like I'm actually writing any data to the flash array. PPAGE and ROMON are at the correct values but when I check the memory location using the debugger, it's showing all FFs.

I have found something about block protect bits that need to be cleared in the document AN2166 but I can't find which register those bits are actually in. The closest I can find are the FPOPEN and BOOTP bits. FPOPEN is set, so it seems that the whole Flash array should be enabled for program/erase and I'm not writing to the sections that BOOTP protects (I am writing to $8000 on PPAGE 1).

Anybody have any guesses as to what I'm missing?

Thanks!

[kef]

• when I check the memory location using the debugger, it's showing all FFs.

You need to modify Debugging Memory Map in debugger to make flash contents refreshed when you halt your target or step. By default flash and EEPROM are cached by debugger to speedup BDM communications. See CrasyCat's response here:

https://community.freescale.com/message/48300#48300

[FallSe7en]

Thanks so much for your continued help. Unfortunately, I've run into a new problem...

I've been able to write/read to and from the Flash successfully now. The problem is, I've noticed that setting PPAGE to new values isn't actually doing anything. For example, I'll set PPAGE to 0 and write a message to the top of that page. Then, if I set PPAGE to 1 and read from the top, the message I wrote to page 0 will still be there. I feel like I'm missing a step after setting the PPAGE register...

[kef]

Are you reading from PPAGE 1 using debugger? I don't have unit with this MCU at hand and can't verify, but I think that you should read PPAGE 1 at 0x18000, PPAGE 2 at 0x28000 etc. For 912Dx what you see at 0x08000 probably doesn't depend on PPAGE register and is always PPAGE 0.

[FallSe7en]

Does that mean I should be writing to $48000 if I want to write to PPAGE 4? So really, the only reason setting the PPAGE register is important is that it gives access to the right flash array's control registers then? How come in the databook they talk about a 16K Page Window at $8000-$BFFF for the eight 16K Flash EEPROM Pages?

[FallSe7en]

I thought of another question--also, doesn't the MCU use 16-bit addressing? Wouldn't 0x48000 be more than 16 bits?

[kef]

Yes, HC12 is 16bits MCU, which can access all extra flash via PPAGE window. 0x08000, 0x18000, 0x28000,..  - it is just how Codewarrior debugger represents paged flash.

[FallSe7en]

Ok, so my code should still read/write from/to the window at $8000-$BFFF but when I check for it in the debugger, I should look at the other addresses ($48000 for PPAGE 4)?

[FallSe7en]

Sorry about inundating you with questions, but I've got another...

I just tested writing to PPAGE 4 by writing to the window at $8400. The debugger shows the proper data at $8400, but nothing (just 0xFF's) at $48400. Does this mean that my Flash programming code is incorrect?

[kef]

I found old board with 912DT128A. I set PPAGE=4, flashed something to $8000 and stopped MCU. Debugger shows new data at $48000... So looks like your code is doing something wrong. But how? Are you setting PPAGE and then calling flash programming routine? Then probaby you still are using banked memory model, where majority of functions is called using CALL instruction, which changes PPAGE. Is it the case?

[FallSe7en]

Aha! That was it! I was using the banked memory model. I'm finally reading/writing the Flash array properly. Thank you so much!