Assembly Program Won't run

[Rodo55]

Hello,

I wrote an assembly program and I can download it into the DEMOQE demo board and QE8 uC with the CodeWarrior debugger and it runs just fine. It does everything I asked it to do.

I can download the program and I run it for a while and it runs great but if I shutdown CW and I power cycle the DEMOQE board the program won't run on it's own. It acts like it's dependent on CW.

Does anyone have any suggestions as to why the program wouldn't run on it's own once it is downloaded into the uC?

Thanks,

Rodo

[CompilerGuru]

Please do not post the same problem to multiple forums, at least not with mentioning that so that duplicated answers are avoided.
To check:
- do you handle or disable the COP?
- is the reset vector set?
- check write once registers, with the debugger they can be written multiple times but not in normal modes.

Daniel

[Rodo55]

Hi Daniel,

Sorry about the double post. I didn't receive any responses in the codewarrior forum so I thought I may have posted it in the wrong forum. I didn't see any way to move the post to the 8 bit forum so I reposted it there. Thanks for the friendly reminder. I'll mention that I posted the same question in a different forum if I ever have to repost again.

I disabled the COP timer in my program

I used the defaults from the standard assembly vectors from the assembly template:

ORG $FFFA

DC.W spurious

DC.W spurious

DC.W _Startup

ORG $FFCE

DC.W IRQT       ; My RTC Interrupt Routine

The write once registers are correct.

Like I stated the program runs fine as long as it's started with CW.

It just won't run without CW.

Rodo

[kef]

Hi

---

The write once registers are correct.

Like I stated the program runs fine as long as it's started with CW.

It just won't run without CW.

---

Daniel meant that maybe write once registers are write once in normal modes but write many times in special mode. Normal is when you power up or reset your board with BGND pulled high, special is when reset or power up keeping BGND pin low.

Searching through QE8 manual I found 3 write once registers SOPT1, SOPT2 and SPSMC1. Write once means that you should write for example SOPT all bits at once and only once. It's not allowed to write for example SOPT1_COPE bit (using C bitfields), then  write SOPT1_COPT bit. First write is granted, the second is ignored and all further are ignored until next reset.

I don't see mentioned in QE manual if QE's write once registers are write many times in special mode, but the most of S12/S12X write once registers do become write many times in special mode. So one may violate write once requirement while debuigging and feel confident about his program. Of course it's very likely such program won't work in normal mode.

Message Edited by kef on 2008-07-11 09:08 AM

Message Edited by kef on 2008-07-11 09:09 AM

[peg]

Hi,

Well I'm not 100% sure about this, but I want to dispute all three of the Guru's suggestions as possible reasons why it might run on the BDM and not without as far as S08 is concerned.

The COP is only disabled in active background mode if you RUN the device with the BDM connected it will trip on the COP if it is not handled.

If you don't set the reset vector it will tell you. I think you can force run from a certain location but you can't just go and hit RUN.

I have never seen in a S08 manual where write once registers become write many. I think this may be peculiar to 16-bit S12.

Please dispute the above three statements if you believe them to be wrong for S08!

[kef]

Peg, you are right.

I wasn't sure about write once-many time thing, especially manual doesn't mention it. However this BDM-noBDM difference... I just verified and made me sure that QE128 write once registers are write once even in special mode. So this S12 idea seems to not apply to S08. Except that FPROT is freely writeable in special mode, but that's documented.

Uninitialized COP vector also doesn't apply to S08, since there's no seprate COP vector like in S12.

Rodo, I think you should start debugging hard way. Blink LEDs or SCI putchar before, after initialization and in main loop.

If there's really no difference in hardware between modes, then what? I guess you flashed the program, or maybe hit reset in hiwave, and it run well. What's the difference between run button and normal power on and run sequence? A delay between power on and hitting run button vs power on and immediate run? No ideas

[Rodo55]

Thanks Kef,

I'm at a loss too.

I was thinking there was some sort of boot loader that was integrated into the restricted flash locations and maybe the BDM emulates the boot loader and doesn't use the internal one. But when the chip is stand alone it uses it's internal boot loader.

I don't know, I'm new to the microcontrollers so I was hoping the much more experienced programmers would be able to say "I've seen that before and here's what you did wrong".

Or, there's some option I accidentally set in CW that says don't install a boot loader. That way the program wouldn't run as a standalone program.

Thank you everyone for your help and suggestions.

I'll keep plugging away and get it running somehow.

Rodo

[peg]

Hi Rodo,

There is no bootloader as such. Programme execution just starts at the address programmed into the reset vector location.
Here is some other things to check for:

Something on the BKGD pin causing the device to enter background mode on power up.

There is a polling loop in your code that never falls through. With the debugger connected you are reading a location, which clears a bit which allows the loop to exit. Without the debugger read it never occurs. Stop all access by the debugger to test this.

Power supply issues that are "fixed" by the debugger connection. (i.e. no 0v connection fixed by the USB cable)

Otherwise strip your code down to a minimum and post it here.

[Rodo55]

Hi Peg,

I just figured out the line of code causing the problem. It took a while to track it down.

The issue comes up when I disable the LVD module.

In my code I'm writing a #$00 into SPMSC1 to disable the LVD module and conserve battery power.

If I change it to #$0C the program runs without CW or the debugger just fine but if I change it to either #$08 or #$04 the program will not run without CW debugger.

I don't know why disabling the LVD module would cause the program not to run without CW.

I disabled it because I want to conserve battery power.

Looking through the QE8 resource manual I don't find any correlation between CW and the LVD.

I appreciate your help and patience with me.

Rodo

[kef]

Rodo, I attached oscilograms of DEMOQE VDD. TEK0000 is taken powering demoqe by plugging USB cable to laptop with DEMOQE power switch in ON position. Another one is taken switching power switch from OFF to ON. I think some sort of brown out protection is necessary, at least during this noisy power up.

I wonder why you disable LVDRE. I think LVD reset enabled doesn' t consume more power than LVD reset disabled. Reset on power drop is what should protect you from runaways in brown out condition.

It may be a good idea to clear LVDSE and disable LVD in stop mode to conserve power, but then I think you should exit stop mode periodically to enable LVD for a moment to check if battery didn't discharge and reset if it did. Also before entering stop mode I would check LVW status and enter stop only if power is OK.

I'm not sure in what cases one should fully disable LVD. Maybe only when one is very confident about always present power supply. But then there should be some other ways to check if power is good.

It's not clear why $0C in SPMSC1 worked and $08 and $04 not. Do you enter stop mode immediately after reset? If so then brown out and runaway could happen in stop mode. Why then $0c worked? Maybe higher power consumption due to enabled LVD changed VDD waveform and runaway didn't occur? Interesting.

[Rodo55]

Here's some more information.

As an experiment I changed the stop mode from 2 to 3 and I disabled the LVD.

The program works OK.

In Stop mode 3 if I disable the LVD the program runs stand-a-lone.

In stop mode 2 if I disable the LVD the program will NOT run stand-a-lone.

Therefore there is a correlation between the stop modes and the LVD that causes the program not to run.

This all so confusing.

rodo

[kef]

I attached those oscilograms because I found it weird you are shutting LVD off. TEK0000 oscilogram clearly requires LVD enabled at least until VDD stabilizes. Haven't you heared about something like self erased flash or other problems caused by lack of LVD reset circuit? Older chips didn't have builtin LVD and zilions of circuits included external LVD reset circuits. There's some >0V voltage level, below which MCU is not guaranteed to run properly (bad things can happen). Reset should be held low whenever VDD is below this safe margin. TEK0000 picture shows how you can get dangerous to low voltage condition at power on. Voltage was rising until ~2V, reset probably was released and program started executing initialization and maybe shut LVD reset off. Then suddenly VDD goes down well below specified minimum. Chances are it will execute properly, but Murphy's law and electrical specs say it should runaway or something.

I'm not sure if you board runaways or if there's some errata making your system unable to start standalone. I think runway is very likely with LVD shut down even at power on, unless you have very clean and quite fast VDD rising edge.

I understand your confusion why FSL allows to shut LVD off. One may wish to use some external system management chip. Some voltage regulators do have built in power good circuits etc. You are monitoring 12V  supply. That could be another reason to shut VDD off. But at startup you shouldn't shut VDD reset off before you see enough volts on 12V bus. Is this delay until power good implemented?

I'm not sure why there's a correlation Stop2-3-LVD. Chances are CPU will run at too low voltage, chances are, too, CPU will hang at too low voltage.

[Rodo55]

Kef, I have not heard about self erased flash before.

I am new to MCU's and with everyone's help I have learned a lot about MCU's but I still have a lot more to learn.

I'm running the program on the QEDEMO board with a QE8 MCU on it. So presently I do not have the 12 volts and some of the other circuits running. The power test is using the power on/off switch on the board. Maybe this won't be an issue when I build my board because the MCU will be powered all the time.

If I read your oscilogram correctly it looks like I'd need a 70 ms delay to allow the power to stabilize before executing the program if I still want to disable the LVD module?

If I understand the resource manual properly Section 5.6.1 (see below), I don't need to delay 70 ms because the QE automatically holds until the voltage reaches the proper level before it executes the stored program?

But, If I understand your notes I still need a delay because even though the QE may have initially seen a good voltage level and started the program your oscilogram shows a spike in the voltage and a decline which may or may not be enough to sustain the execution of the program. So a 40 ms or so delay before shutting off the LVD may be required?

5.6.1 Power-On Reset Operation

When power is initially applied to the MCU, or when the supply voltage drops below the power-on reset re-arm voltage level, VPOR, the POR circuit will cause a reset condition. As the supply voltage rises, the LVD circuit will hold the MCU in reset until the supply has risen above the low voltage detection low threshold, VLVDL. Both the POR bit and the LVD bit in SRS are set following a POR.

Am I making this harder than it should be and I should just leave the LVD module on? It probably doesn't use that much power anyways.

Thanks Again,

Rodo

[kef]

Let's look into QE8 datasheet.

1. Operating voltage min = 1.8V, max = 3.6V. These are the limits MCU is guaranteed to operate properly.

15. POR (power on reset) re-arm voltage. Max = 2.0V. Allright! MIn = 0.9V :smileysad: not alright. If you think QE8 datasheet is too preliminary, then look at old parts specs. I think they have similar figures for POR re-arm.

17. Low-voltage detection threshold, Vdd falling. Min 1.80V, max 1.88V. Both figures are within operating voltage limits.

LVD guarantees safe reset state on voltages below operating voltage limits, while POR circuti - doesn't.

In most of cases you really need some kind of LVD reset.

Speaking about self erasing flash I didn't mean S08 but all MCU's. Yes that's possible, especially on older MCU families. Like Peg said, ANYTHING can happen out of spec, I add that flash self erase too.

Edit. Oh, about delays. Constant power-on time delay won't always work. You may build another board with higher capacitance on supply rails and delay will change. I suggested to wait until voltage rises to power-good level 12V bus. Then you could switch to software-LVD monitoring 12V bus. When bus drops to too low level I think you need to reset using illegal opcode/adrress, cop, or some other kind of reset. After reset everything will repeat, new delay waiting for proper 12V etc.

Regards

Message Edited by kef on 2008-07-13 09:19 AM

Message Edited by kef on 2008-07-13 09:20 AM

[peg]

Hi Rodo,

When you allow a processor to run at an out od spec voltage level ANYTHING can happen.
Most are recoverable by POR. Some are not.
Erasure of flash is one of those that are not. Failure due to an invalid combination of outputs is another.

I think I would be starting a Service Request on this issue.

You said you still have the problem with SPMSC1 at $08. This should not happen as the LVD module is disabled and so other bit functions have no effect.
You are taking into account the write once nature of bit 2 here, aren't you.

Also with bits 4 and 5 at zero the LVD module could be operational but does not do anything other than indicate the module status at bit 7. Again are you sure you are not trying to write more than once. Bit 4 this time.

What if you remove all stop modes from your programme. Does this allow it to work properly?

As it is necessary to do what you are doing (and disconnect the BDM adapter) in order to check for lowest stop current you can be sure that someone has already managed to achieve this. If only the test engineers at Freescale.





Message Edited by peg on 2008-07-13 09:37 AM

[Rodo55]

Peg,

The configuration of the SPMSC1 register is only done once during the initial configuration of the MCU.

If I use Stop mode 3 the program works fine. When I turn on the power the program executes like it should.

If all I change is the mode to STOP mode 2 the program will not run when I turn on the power.

I'll open a service request and see what they say.

Thanks,

rodo

[Rodo55]

Thanks Kef,

I appreciate the Oscilograms, it shows the noisy way the chip powers up. That's good to know.

I don't need the LVD because I use a 12 volt battery for my power and I have 5 volt parts on the board as well. So what I do is I monitor the 12 volt supply and if it drops below a certain voltage, I flash a power light that indicates a low voltage condition long before the LVD would ever know one existed.

I tried turning off the LVD because my understanding is, any module running consumes power, therefore I tried shutting it off. Where I'm confused is why shutting off the LVD causes the program not to run. I don't read any dependencies between the LVD and running a program on the QE8?

And if one existed why would Freescale provide a register where you could shut it off. I've looked in the QE8 data sheet and the QE8 resource manual and I don't see any reason for it to stop the program from running.

But, looking at your Oscilograms and reading the way the LVD works it may go into a shutdown mode due to the brownout and not even allow the program to shut it off. But again why would that only be an issue when I try to shut off the LVD module? If I don't try to shut off the LVD the program runs.

Is there an option I missed? The resource manual has a note to disable other modules before shutting off the clock to them to conserve power . Maybe there is another register that needs to be addressed before I try to shut down the LVD. I don't see the reference but there might be one.

Thanks again for your help,

Rodo

[CompilerGuru]

I see that some points apply for the S12, not for the S08.
Not setting the reset vector is not a problem, it will run fine as long as you do not reset it. Basically the debugger sets the PC initially to the address given with ABSENTRY, and the main use case this is for is debugging small code pieces from RAM without flashing anything. Not the most common setup for a S08, but still useful in some special cases.

Daniel

[Rodo55]

Thanks Daniel,

I'm not sure I understand your point so I'll include some info:

below is the template CW uses for assembly and is what I'm using.

; Include derivative-specific definitions
            INCLUDE 'derivative.inc'
; export symbols
            XDEF  _Startup
            ABSENTRY _Startup
            XREF __SEG_END_SSTACK   ; symbol defined by the linker for the end of the stack

_Startup:
            LDHX   #RAMEnd+1        ; initialize the stack pointer
            TXS

            BSR MAIN_INIT
mainLoop:           
           
            SEI  ; Disable Interrupts

     THE REST OF MY CODE HERE

      END OF CODE

                 ; Interrupt Vectors  

            ORG   $FFFA
            DC.W  spurious          ;
            DC.W  spurious          ; SWI
            DC.W  _Startup          ; Reset

I reset the SP so I don't have memory over runs.

Is this an issue?

Rodo

[Rodo55]

Hello,

I set the write once registers in an initialization routine that is ran at the beginning of my program and is not part of the main loop so it's only ran once. That is also where I disable the COP. So, I don't believe I write to them more than once anyways.

Peg, I disabled the BDM and the program still won't run. CW loses contact with the DEMOQE board so the BDM seems to go inactive. The program still doesn't appear to be running though. I have a status LED which doesn't blink so that tells me the program isn't running.

Any thoughts anyone?