strange behaviour without debugger - MC9s12xDP512

[lak]

Hi Forum,

I am seeing strange behaviour of my software working when debugger is removed and the unit is run in normal standalone mode. Sometimes, the processor resets or hangs up somewhere else. I am working on the MC9s12xDP512 device using codewarrior 4.5 along with P&E usb multilink for debugging.

This behaviour is not very repetitive, occurs sometimes but with debugger the software runs properly every time.

Am i missing some registers/some initialization which the debugger was doing every time to make the code workable?

i did go through most of topics on forum relating "works only with debugger" but could not reap much out of it for my issue as it is not very repetitive.

I have not enabled the internal COP, but not sure whether is it enabled by default when the chip gets into normal chip mode(which i learnt to be the one entered for normal power on and the special chip mode if debugger is connected).

please advise me what could be wrong in this case.

Added, this software crashing, even though happens once a while, happens to occur at a particular location where i jump to a function in RAM. I am using small memory model only and accesses are within the same page.

with regards,

Lak

Added p/n to subject.

Message Edited by NLFSJ on 2008-01-24 08:51 AM

[Lundin]

I think that the debugger might write to the INIT registers INITRG, INITRM and INITEE. In any case, you should write to them manually. Are you doing this?

And why do you have code in RAM?

The COP is not enabled by default, you must enabled it manually.

The problem could also be hardware-related. You should have a pull up on the MODC/BKGD pin, and tie MODA and MODB to ground. And (needless to say) the reset pin must also have a pull-up.

Kef's advices are good: if you write several times to write-once registers, you might experience the kind of behavior you describe.

[JimDon]

How does that code get into ram?
Do you re-write it from flash on reset?

The obvious answer is that you have a wild pointer somewhere and are messing up the code in ram, or the stack pointer is overwriting the ram code.

And perhaps it is timing related, so that in the debugger it does not happen.

Of course this "obvious answer" does not give you a clue where the problem is :smileywink:.

[lak]

Hi all,

I tried to see whether it was due to an illegal address reset. As I have to observe without debugger,I had placed some stub routine to output the CRGINT register value thro' SCI in all my unimplemented isrs before it can reset. After many attempts, the code crashed once and I could see that in this register, ILAF was not set(it read as 0x80). Also the COPCTL was read as 0x00 too. So, I don't see it could be due to illegal address.

coming to the hardware check, the pins are pre-tied in the same state as kef had suggested.So, could not be hardware issue.

Going further, I added few more traps in the cop/clockmonitorreset/unimplemented/SW1 isrs to output some message, just to see which was the source of interrupt causing this crash(Is there any other better way to know the source of interrupt?). However after this, I have tried number of times to reproduce the crash, but has never appeared till now.

I am working on a bootloader and so jumping to a function to execute from RAM, which is declared in a seperate READ ONLY section within RAM in the linker time, I feel the address is proper as it is generated during compile/link time only.Also, I have observed when connected the debugger, it jumps to the proper RAM location where it is located and executes from there.

Only the stack pointer check messing with this area is to done, but I am trying it out, as the error is not repeatable.

As Lundin mentioned, I don't see the INITRG,INITEE .. registers for the MC9S12XDP512 device to be initialized. Are there any equivalents?

Is there a list of WRITE ONCE registers which I need to take care. please let me know..

Also, what would happen if BGND instruction is encountered in normal single chip mode? Would it reset the micro. With my debugger, i have seen it stop and say illegal BP.

I have this in all my unimplemented ISRs as the last instruction.

with regards,

Lakshman

[Lundin]

READ_ONLY sections in RAM will only be valid til you get a reset or power-down. If you don't restore them after that, they may contain random garbage, as RAM is volatile memory. If I'm correct, Codewarrior provides no automatic copy-down from flash to RAM of such code, you will have to write it yourself explicitly. It is still not clear if you have done this or not. If you haven't, but only download the code into RAM from the BDM, your program will behave randomly.

Regarding the INIT-registers, I apologize for bringing them up as S12X seems to lack them, which I didn't realize, since Freescale claims it to be code-compatible with HCS12. I don't know if there are equivalents in S12X.

Executing a BGND instruction will give you a software interrupt (SWI). How it will behave depends on what address you have in the interrupt vector table for that interrupt. Debuggers most likely relies on this interrupt for their breakpoints, which is why you might get odd messages from the debugger.

List of write-once registers in HCS12 :

http://forums.freescale.com/freescale/board/message?board.id=CW816COMM&message.id=3478

The above thread might also be helpful to you as it discusses a problem similar to your own.

[lak]

The strange behavior got more explained today as I ran a further RAM sanity check. As Lundin suspected rightly, the location in RAM, where my code used to jump to the resident function, turned out to contain garbage. I always presumed that the codewarrior startup used to copy my code to RAM but it never did, the BDM debugger was doing it and the software worked fine. As I mentioned earlier I had allotted a code section in RAM in my linker file to hold these functions. To the interesting part how it used to work most of the time in standalone mode, I had my pc serial port always connected on to the SCI1 of my hardware for debugging purpose. My friend here observed that even after power was removed, it measured 1.5V which inturn tied to Vcc,sufficient to retain the previous RAM contents(code),which were there after I had flashed thro' debugger, initially. As long as these connectors were there, the RAM code remained intact. So, we removed all the connectors and yes, the problem occurred repeatedly, each and every time leading to garbage values. But still, I ponder whether I was totally wrong in assuming it was the codewarrior's responsibility to locate the code into RAM since it allows such provision of READ_ONLY in its linker file? Is there any linker setting which shall command the startup to copy code to RAM everytime? But,a great thanks to all of you for your timely and expert advices. Once again the forum proved its worth. with thanks, Lak

[JimDon]

Lundin is correct - if you declare it as read only then it assumed to be FLASH, and there is of course, no reason for startup to re-copy it on reset.

If you declare it as R/W then startup should copy it on well, startup.
The debugger "burned" it because after all it thinks it flash, so when you down load the program of course it must be written as part of the flashing.

If you think about it makes sense that read only memory would be assumed to be flash, and therefore would remember what was burned there. Then only signal to the linker that it is not flash is telling it that it is read/write.

You can't really blame the tools - after all you did lie and say it was read only :smileyhappy:.

[kef]

---

Lundin wrote:
Executing a BGND instruction will give you a software interrupt (SWI). How it will behave depends on what address you have in the interrupt vector table for that interrupt. Debuggers most likely relies on this interrupt for their breakpoints, which is why you might get odd messages from the debugger.

---

Lundin, you are not right regarding BGND opcode in normal modes. It doesn't give SWI interrupt. BGND description is quite long to post here, but in short, BGND enables BDM ROM, jumps there, executes some code from BDM ROM, and if BDM is disabled, then execution resumes in the user code at instruction following the BGND. You get a long NOP. You probably mixed it with hardware breakpoints in normal modes. In BDM mode breakpoints stop the program and control is passed to BDM ROM. In user mode breakpoints cause SWI interrupt.

I decided to test how long does the BGND take in normal mode. CPU manual states that BGND should take 5 bus cycles. It doesn't count in time needed to return back. Using timer I measured more than 60 bus cycles for all 3 HC12 generations. HC12 and S12 - 57cycles, S12X - 61 bus cycle. :smileysad:, I used to think I don't have to recompile release code with BGND's removed.

[kef]

Lakshman,

Are you writing to CRGINT register, possibly when enabling RTIE, LOCKIE and SCMIE interrupts? If so then you may clear ILAF if you use bitfields to access RTIE, LOCKIE or SCMIE. You can enable RTIE without clearing ILAF this way:

CRGINT = (CRGINT & ~CRGINT_ILAF_MASK) | CRGINT_RTIE_MASK;

If aren't using above mentioned interrupts and ILAF is cleared all the time, then it's not ILAF reset. Oh, but you write that you read 0x80 ?from CRGINT?, then please check how you are enabling RTI interrupt.

Remember that COP and clock monitor resets are *resets* and you should init SCI or whatever comms hardware you are using.

READ ONLY section doesn't prevent stack overflows. Some write access using uninitialized pointer and section changes its type to R/W.

There's no more INITRG/EE/RM and equivalents. Bootloader can use VBR to move vectors to somewhere else.

BDM in normal mode by default is inactive. With BDM inactive, BGND instructions should be something like like NOPs, almost "ignored". You may try using hotsync/hotplug debuggers option to connect to the target without reset into special single chip mode. Then BGND instructions should become activated again. But maybe I'm mixing something and need to refresh my memory... hope not.

Regards

[kef]

It could be an Illegal Address reset. In normal single chip mode, any access, (either read or write) to unimplemented memory areas causes an illegal address reset. There's a ILAF flag which indicates if reset was caused by illegal address reset or not. 

Configuration byte at 0xFF0E (global 0x7FFF0E) controls if COP is enabled or not. If you didn't overwrite this location, then COP should be disabled by default.

Also its worth to check if you aren't writing twice or more times to write once registers. Write once registers are write many time register in special modes, exactly when you are debugging via BDM.