Stuck before "main" during runtime

[brian_kbs]

Hi,

I'm using the MC9S08QE8 with CodeWarrior 6.2, and I'm having some difficulty during debug.

My code compiles with no errors or warnings, but when I load it into the processor for debugging and try to run it, it gets stuck before "main" function. I get some messages about the clock frequency changing. When I hit "stop" in the debugger, the program counter is at zero.

This behaviour seems to be very sensitive to exactly what lines of code I insert or delete. Sometimes I delete a line of code and everything is OK again for a day or two, before I run into the problem again. I haven't found any pattern as to which lines of code affect it.

Does anyone have any suggestions what might be causing this?

Please also tell me what other info I should add to this post - I'm not sure what's relevant! 

Thank you! 

[stanish]

Hi,

Did you customize your startup file or you use the default one? 

Do you use ProcessorExpert?

Do you init PLL in startup? 

It might be worth to check if it's caused by watchdog reset.

I'd suggest you to step through the startup to isolate the startup code that causes this problem.

Stanish 

[brian_kbs]

Hi Stanish,

Thanks for the quick reply! Here are the answers to your questions, as best I can...

I'm using the default startup file.

Yes, I'm using Processor Expert.

I don't really understand the code, so I'm not sure if the PLL is initialised there! The function _EntryPoint looks like it might be doing it though. All I've done is just set up the clock speed etc. in Processor Expert and let it do its stuff.

I stepped through the startup code and the problem occurs after the "copy down" section of the Init function. I step through it for a while but it takes a long time so I hit "resume" and the debugger loses the connection with the target processor. I guess that sounds consistent with a watchdog reset but I'm not sure how to verify that.

There seems to be an option to feed the watchdog during the copy-down, so I tried defining the macro _DO_FEED_COP_ in my main C file, but it didn't change anything.

Thank you, 

Brian

[brian_kbs]

Hi all,

Well, I found out what's causing my problem, but I don't know how to fix it! 

I've realised that my problems occur only when my flash image goes beyond address 0xC000. And it turns out that the end of my flash image is almost *exactly* at this address. (That's why if I comment out a few lines of C code everything behaves OK!)

Everything beyond 0xC000 seems to be garbage, whereas everything before it is OK. (The startup code reads some of this rubbish data, resulting in the strange behaviour I originally posted.)

It looks like my P&E programmer just stopped sending data when it reached a 16kB limit. This shouldn't happen as the chip I'm using has 32kB of flash. (As proven by the fact that the startup code is able to read garbage from higher addresses! :smileyhappy:  )

So... how do I send more than 16kB of flash data to my chip?

Thanks,

Brian 

[bigmac]

Hello Brian,

What device are you actually using?  I presume it is not the MC9S08QE8, as you originally posted.  For this device the flash starts at address 0xE000.  The address 0xC000 would be an invalid address for the 'QE8.

Incidently, for the larger 'QE128 device the address range 0x8000 to 0xBFFF represents the paging window, and the visibility of other memory within this range would depend on the PPAGE setting.

Regards,

Mac

[brian_kbs · Accepted solution]

Hi Mac,

You're absolutely right, I quoted the wrong device number. Thank you for spotting my error. It turns out that the PCB schematic had the wrong label on it, and that's what I referred to when I was posting above. Sorry if this caused confusion for people (it certainly did for me!)

As for the memory problem, I got a <i>flash</i> of inspiration (cough cough) from another post here by Kopone. ("Tell debugger to mass erase only 1/2 flash...") In the debugger, I went to

MultiCyclonePro -> Advanced Programming/Debug Options

...and saw that the range of memory from 0xC000 to 0xF9FF was "protected". I'm not sure why. Is this a default setting? Otherwise it must have been selected by the guys who developed the original version of the project I'm working on, and they forgot to write it down.

Anyway that explains the problem. This address range was not getting erased before the new data was written to it, so the data got corrupted. My code starts up OK now!  :-)

Thanks for the help guys.

Brian