Cant use BDM in Real Time to Test Application that modifies Flash/ HCS0808QG8

[YeOldeBDM]

I am developing an application for the HCS08-QG8 using CW 3.1 and the USBMultlink12 BDM pod.

The application uses one page of FLASH @0xE000 to store non-volatile data for calibration instead of using a separate serial eeprom.

Machine instructions in another page of flash erase, write, read the calibration page. This is permissible for the QG8, although other Motorola microcontrollers cannot do this.

I have a function to erase the calibration page of FLASH. When I single step through this function with the True Time Debugger and BDM pod, everything works as expected. But When I try to execute this function in real time using the BDM, the debugger reports a mysterious bus frequency change and the application jumps to unprogrammed locations.

The function disables all interrupts. The assembly code in the listing is consistent  with the requirements in the QG8 manual to erase the  page of flash 0xE000-E1FF.

Using the expert mode programmer in the True Time Debugger, I can alter values in this page and watch and then watch the page get erased after the erase command is launched, but only while single-stepping.

I have attached a disassembled C function. The assembly code is consistent with all the requirements in the QG8 manual to erase a page of flash.

If you have any insights, I would appreciate hearing from you. I have seen one other thread regarding this issue, but it appears that thread left this issue unresolved.

We had some issues like this with an 9S12 processor and a BDM, but in that case, one could not single step-- one had to execute in real time to make things work. These issues were never resolved either.

[tonyp]

You write:

Machine instructions in another page of flash erase, write, read the calibration page. This is permissible for the QG8, although other Motorola microcontrollers cannot do this.

Where exactly did you see this in the reference manuals?  AFAIK, you need to be running from a separate memory (usually only option is RAM) when programming (erasing or writing) Flash.

[YeOldeBDM]

tonyp- Thank you for taking the time to reply.

Referring to the QG8 manual, page 49:

"One use for block protection is to block protect an area of FLASH memory for a bootloader program. This bootloader program then can be used to erase the rest of FLASH memory and reprogram it. Because the bootloader is proctected, it remains intact even if MCU power is lost in the middle of an erase and reprogram operation"

The other source was a telephone call from the local FAE. He said the QG8 did not need to program flash from ram like an LJ12 processor.

Perhaps the bootloader must be copied down to ram and the FAE was incorrect. Can you point me to documentation that states this? Anyone?

[YeOldeBDM]

It appears tonyp is correct--you must execute out of ram. From the QG 8 reference manual, we go back to the HCS08 Family reference manual, then back to Application Note 2140, which describes a bootloader (in assembly) which "uses no ram other than the stack itself"

Going into the application note, we find they load machine instructions onto the stack to manipulate flash.

[peg]

Hi,

Have you seen this thread

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&message.id=1066

Regards David

[YeOldeBDM]

Thanks David.  I went over the thread and its the same issue.

BTW, if anyone is using C and has to execute out of RAM, Metrowerks TN228 gives you the necessary information.

[irob]

YeOldeBDM, have you gotten TN228 to work? I'm having very weird results in single step on a DEMO9S08QG8 board. It immediately jumps into the weeds.

I do get a "C1805: Non standard conversion used" warning at this line:

dstPtr = (char *)&func;

Something about that casting is foobarring it.

Also, this line in TN228:

#pragma CODE_SEG DEFAULT;

produces a "C3802: Segment pragma incorrect" warning. Any ideas?

Message Edited by irob on 2006-06-29 02:08 PM

[YeOldeBDM]

Sorry, irob I have not bothered to modify flash in ram. We have decided to do the calibration and put the constants in my application by Cyclone programmer rather than serial link.

-I dont usually include a semicolon after a pragma. You have to get rid of this error first.

-pointers to functions- always confusing. Is this a pointer to a function that returns a char?

Sorry I cant offer specific advice. When I get problems like these, the first thing I do is get rid of the errors (always) and warnings (almost always), and then inspect the map file and disassembled code to see if it matches my expectations.

[irob]

Thanks for the help, YeOldeBDM (hilarious user name, btw!).

You were right. Brain fart on my part with that semicolon. That warning is now gone. After correcting that, I got a new warning:

C4200: Other segment than in previous declaration

It had to do with how I was interpreting (wrongly) the TN228 document. It wasn't very clear to me where the prototype for the RAM copied function func() was supposed to go. From page 1 of TN228, they failed to mention that it needs to go within that segment declaration.

So, that warning is now gone. And as far as the function pointer warning, I just plunged back into the demo board with this code as it stands. And it works fine!