Chip Crash

[DanielMorley]

I am using a Multilink to programa MC9S08GT8A.  It gives me the following error

!OPEN source 0 0 60 39
NO CONNECTION
!Source < attributes MARKS off
!OPEN assembly 60 0 40 31
!Assembly < attributes ADR on,CODE off,ABSADR on,SYMB off,TOPPC 0xF88C
!OPEN procedure 0 39 60 17
!Procedure < attributes VALUES on,TYPES off
!OPEN register 60 31 40 25
!Register < attributes FORMAT AUTO,COMPLEMENT None
!OPEN memory 60 56 40 22
!Memory < attributes FORMAT hex,COMPLEMENT None,WORD 1,ASC on,ADR on,ADDRESS 0x80
!OPEN data 0 56 60 22
!Data:1 < attributes SCOPE global,COMPLEMENT None,FORMAT Symb,MODE automatic,UPDATERATE 10,NAMEWIDTH 16
!OPEN data 0 78 60 22
!Data:2 < attributes SCOPE local,COMPLEMENT None,FORMAT Symb,MODE automatic,UPDATERATE 10,NAMEWIDTH 16
!OPEN command 60 78 40 22
!Command < attributes CACHESIZE 1000
!bckcolor 50331647
!font 'Courier New' 9 BLACK
!AUTOSIZE on
!ACTIVATE Data:2 Command Procedure Data:1 Source Register Assembly Memory 
done C_layout.hwl

Loading Target ...
Windows NT detected.
USB HCS08/HCS12 MULTILINK detected - Flash Version 5.55
Frequency change to ~7788928hz.
USB HCS08/HCS12 MULTILINK detected - Flash Version 5.55
Frequency change to ~3882624hz.
Device is 9S08GT8A.
Mode is In-Circuit Debug.

IO registers loaded for MC9S08GT8A from C:\Program Files\Freescale\CodeWarrior for HC08 V5.1\prog\REG\MCU101F.REG
executing .\cmd\BDM_P&E_Multilink_CyclonePro_startup.cmd

!// At startup the commands written below will be executed
Target Ready
done .\cmd\BDM_P&E_Multilink_CyclonePro_startup.cmd

Startup command file correctly executed.
executing .\cmd\BDM_P&E_Multilink_CyclonePro_preload.cmd

!// Before load the commands written below will be executed
done .\cmd\BDM_P&E_Multilink_CyclonePro_preload.cmd

Preload command file correctly executed.

Loading 952 bytes.
executing C:\Documents and Settings\Daniel_Morley\My Documents\accuator1\bin\Project.xpr

!Data:1 < ADDXPR ONLY_ADD_IF_NEW "main.c::_ICGC1.MergedBits."
MCU Device Selection has been changed.
done C:\Documents and Settings\Daniel_Morley\My Documents\accuator1\bin\Project.xpr

executing C:\Documents and Settings\Daniel_Morley\My Documents\accuator1\bin\Project.xpr

!Data:1 < ADDXPR ONLY_ADD_IF_NEW "main.c::_ICGC1.MergedBits."
done C:\Documents and Settings\Daniel_Morley\My Documents\accuator1\bin\Project.xpr

executing .\cmd\BDM_P&E_Multilink_CyclonePro_postload.cmd

!// After load the commands written below will be executed
done .\cmd\BDM_P&E_Multilink_CyclonePro_postload.cmd

Postload command file correctly executed.
STARTED
RUNNING
Preset breakpoint encountered.
Breakpoint
Frequency change to ~7804800hz.

Error: Unable to go into background mode.

Frequency change to ~3886592hz.
Warning a RESET has occured.
STARTED
RUNNING
Frequency change to ~7788928hz.

in>

Why is the frequency changing to a 7788928hz when i execut a subroutine to turn on a motor. And what is this present breakpoint?

[Alban]

Hello David,

You have a RESET.

- Does the Reset occurs when the motor is turned on ?

- Does the motor have proper filtering in the command not to slap the MCU with high spikes ?

- Do you use a USB BDM Multilink and have relays for the motor nearby ?

Cheers,

Alban.

[DanielMorley]

You have a RESET.

- Does the Reset occurs when the motor is turned on ?

yes

- Does the motor have proper filtering in the command not to slap the MCU with high spikes ?

the motor is a dc 12 volt motor operating through an external motordriver.

- Do you use a USB BDM Multilink and have relays for the motor nearby ?

multilink is near the motor yes.  I have no relays.

[Alban]

Hi again,

I read similar experience from yb.

You may check for spikes with an oscilloscope. (on BDM/MCU pins)

You can try to either have a better grounding for the Multilink so it's not disturbed by the noise a motor is bound to produce at start-up and during operation.

I read someone put his Multilink in grounded aluminium foil. I don't know if he wanted to do some Debug Tunning of if it really works. May be you can try in order to increase immunity.

But first, have you tried WITHOUT the cable ?

If it work with the cable we can continue investigating this way. Otherwise it's a wrong lead.

Alban.

[DanielMorley]

Hi thanks for your speedy response.  I have removed the cable and checked for spikes and have not seen any. Further more this worked earler just find on another board.  The only difference that I can think of is the addition of serial communication code.  I did try it with out the BDM code and it still crashes. 

[Alban]

Good, it means the cable is not to blame

Have a look at the interrupt vectors of the serial module.

They need to be redirected, even to some stupid code, just in case.

Also, may be the COP is on and you don't give it some nice kick in the backside often enough.

I think you can get the reset source by reading a register and looking at each reset vector was taken.

That should help you finding the source.

Alban.

[peg]

Hi Daniel,

I work with motors all the time.

I would first do what Alban has hinted at and check the SRS register for the source of the reset.

Then I would try it with everthing connected but disconnect just the motor and see if the problem is still there. Usually the problem is caused by the motor current, but not ALWAYS.

Is this a brushed motor?

If not, what type is it?

Is everything properly sheilded and grounded?

[DanielMorley]

It turns out we jumped the gun on the cable issue.  It turns out that the BDM was working and now somekind of short developed in it.  I am not sure how it happed.  Has anyone experienced anything like this or how it is developed.