No BDM-connection

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

No BDM-connection

Jump to solution
3,982 Views
thommes
Contributor III

Hello,

 

I'm using the Mc9s12d64 on a selfdesigned board. My Problem is, that i can't communicatewith the chip.

The NoICE-DEbugger reports the error:

"BDM validation failed: MODE=0xFF BDMSTAT: =xFF

This may indicate incorrect MOD setting (MODA and MODB must be grounded), that the pod cannot reset the target, or an incorrect bus speed setting"

 

I testet the Mod's anb both A and B are grounded.

When i start the communication the Reset-line goes low for 19,5ms then back to 5V, same with the BKGD-line! THe bus speed is set correct (16MHZ crystal => 8MHz Busspeedhttp://dict.leo.org/ende?lp=ende&p=DOKJAA&search=crystal&trestr=0x801). What can be the issue fpr this problem. The crystal also works fine (tested with oscillioscpoe). Can the microcontroller be broken? That would be the first time, this happened....


Please, please help me, because i have no more ideas where i can look for solutions.


Thanks and regards,


Thommes

Labels (1)
Tags (3)
1 Solution
2,767 Views
thommes
Contributor III

PROBLEM SOLVED!!!

The BKGD-Pin of the MCU was not connected to the PAD. But while meassuring the Pin was pushed against it so it was connected....

Thank you very very much for your time and help.

View solution in original post

0 Kudos
23 Replies
2,637 Views
HSW
NXP Employee
NXP Employee

Hello Thommes,

I don't know if that helps, but I've got a PCB with a MC9S12G128 which shows similar symptoms. The problem in my case is that the BDM debugger is somehow not capable of driving the RESET all the way to ground. My reset attempts used to look like this (bottom wave is the BKGD pin):

week_reset.png

The solution was to use a stronger reset driver. The LFBDMPGMR (Freescale's D-Bug12 pod) for example has an optional "buffered reset" drive for these cases. Alternatively, you can hook an external buffer to the RESET output of your BDM pod.

Did you check your RESET is driven at the right level?

0 Kudos
2,637 Views
thommes
Contributor III

Above i attached an image of the reset and bkgd line signals. So the reset controller is okay i think...

I think the probem is that the chip dors not answer via the bkgd-line and i absolutely do not have a clue why :-(

0 Kudos
2,637 Views
RadekS
NXP Employee
NXP Employee

It really looks like your MCU is (partially) dead.

Maybe stupid question: Did you (double) check if your MCU is assembled in correct orientation?

Could you please capture also signal(s) at EXTAL/XTAL pins?

Did you try shortcut instead of R17? XCLKS pin has enabled weak pull-up (25-50KOhm). In extreme case (25kOhm) it presents 0.79V at XCLKS pin in your case.

Maximum input low voltage is defined as 0.35*5V. So, this shouldn’t be any problem, but just for sure… 


0 Kudos
2,637 Views
thommes
Contributor III

I checked the orientation of the Controller twice and it also was checked by a second person.

The signal on EXTAL and XTAL are a clean sinus and a "dirty" Sinus with a frequency of 16MHz. Sorry i cannot use the scope today :-( but perhaps this information is enough for you.

On XCLKS i have nearly 0V. Perhaps 30mV!

0 Kudos
2,637 Views
RadekS
NXP Employee
NXP Employee

Sinus or "dirty" Sinus is not so important information. I would like just know amplitude of these signals (mainly Vpp). Just for case if there could be any issue with crystal. There is typically some minimal amplitude for oscillator – high level = 0.75*VDDPLL .. VDDPLL+0.3V, low level = VSSPLL-0.3V.. 0.25*VDDPLL (for full swing Pierce oscillator/external clock).   


0 Kudos
2,637 Views
thommes
Contributor III

Ah okay, i understand. I will check it monday morning, but from what i remember it was okay. However i will check on monday with the scope - then i will post xtal and extal signals

0 Kudos
2,637 Views
thommes
Contributor III

Hello back again,

I checked XTAL and EXTAL (see attachment). So this seems to be okay right? VDDPLL is 2,5V.

The values are the same, with and without BDM Connection. Does this help, or is this just another hint to a partial broken MCU?

0 Kudos
2,768 Views
thommes
Contributor III

PROBLEM SOLVED!!!

The BKGD-Pin of the MCU was not connected to the PAD. But while meassuring the Pin was pushed against it so it was connected....

Thank you very very much for your time and help.

0 Kudos
2,637 Views
kef
Specialist I

Thomas Pressentin wrote:

When i start the communication the Reset-line goes low for 19,5ms then back to 5V, same with the BKGD-line!

Looks like there's connection between BKGD and /RESET.

Is crystal oscilating? Try powering board up with BKGD tied low. Is ECLK pin oscilating? What frequency?

Make sure you didn't connect 2.5V power pins to 5V supply. Some pins are powered with about 2.5V from internal voltage regulator. Only bypass capacitors should be connected to these pins.

0 Kudos
2,637 Views
thommes
Contributor III

There is no Connection between BKGD and RESET, tested with multimeter.

ECLK pin oscilates with 16MHz. The Power supply pins also have been tested.

Could it be the MCU is broken, because the Pod was connected wrong?

Or just bad Luck an di have found a broken one?

0 Kudos
2,637 Views
RadekS
NXP Employee
NXP Employee

Hmm, that is strange.

You declare there that MCU is new (without code), you have connected 16MHz crystal and you measure 16MHz at ECLK pin (PE4).

In special mode you should measure bus clock at ECLK pin, that means 8MHz.

You can have damaged MCU, but this is really improbably reason.

Can you please check orientation of BDM cable (or BDM cable itself)?

There is application note AN2727 Designing Hardware for the HCS12 D-Family

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2727.pdf

Could you please check your scheme according this application note? Or post here your scheme? I can check it for some obvious error. If your scheme is confidential, please create service request at freescale support web pages https://www.freescale.com/webapp/servicerequest.create_SR.framework


2,637 Views
thommes
Contributor III

This is my scheme. Hopefully this is enough for understanding.

And sorry i did not read carefully. I measured 16MHz at XTAL and EXTAL. On Pin ECLK i measure 5V but without any Frequency.

Normaly the Board should come up in Normal Mode and when the ComPod12 is connected the special single chip mode should be used.

It seems that i can't reach the "Special mode" and therefore i cannot communicate with the Target?

0 Kudos
2,637 Views
kef
Specialist I

On Pin ECLK i measure 5V but without any Frequency.

Normaly the Board should come up in Normal Mode and when the ComPod12 is connected the special single chip mode should be used.

It seems that i can't reach the "Special mode" and therefore i cannot communicate with the Target?

ECLK should oscilate out of reset into special single chip mode. Like Raked wrote, try connecting BKGD to GND and then apply /RESET pulse or cycle power to enter SS-mode. This is what ComPod12 should make when you hit Connect or Reset in debugger.

I think it is just secured MCU. You can't unsecure it from NoICE debugger. I think there should be some utility for unsecuring MCU using ComPod12. Did you check ComPod12 documentation and/or manufacturer's home page?

0 Kudos
2,637 Views
thommes
Contributor III

Sorry for my late answer but i was testing out the things you two mentioned.

I connected BKGD to ground. then reset but wasn't able to see a frequenzy at ECLK. Just the constant5V.

I unlocked the MCU with Code from NoIce, but with no result....

By the way i want to say thank you very much fpr spending time on my problem and helping me.

0 Kudos
2,637 Views
kef
Specialist I

Then you need to verify BKGD connection from BDM connector to MCU pin. Any chance of bad soldering? Powering MCU up or resetting it with BKGD pulled low should make ECLK oscillating, and this should indicate if you can enter SS-mode. Of course you should double check that MODA and MODB are really pulled low.

Do you mean NoICE has special Unsecure command for ComPod12? I doubt it a bit. Like I understood ComPod12 product page, there should be Unsecure function in StarProg software, which comes with ComPod. In case you use unsecure12.noi, don't forget to edit CLOCK_DIV setting to match 16MHz crystal. Unsecure12.noi provides no feedback of what's happening, dedicated ComPod12 software may perform better.

0 Kudos
2,637 Views
thommes
Contributor III

BDM-Pin on MCU and BKGD are conneted. Verified!

MODA and MODB stay GND while reset and also after that.

I used unsecure12.noi and editet the ECLKDIV and FCLKDIV.

No change....at all.

And ECLK is NOT oscilating, when BKGD is grounded :-(

I am going to remove the MCU and replace it by a new one after checking if there are any unwanted connections. Because ECLK not oscilating is a hint for me, that the MCU is not working right...

0 Kudos
2,637 Views
RadekS
NXP Employee
NXP Employee

You can enter into special mode manually: hold MODC connected to GND and reset MCU.

I didn’t found anything really wrong at your scheme.

I suppose that missing layer(s) at PCB layout is just error in this document and not at PCB.

I would like just recommend decrease of R17 (or tied directly to GND). Just for sure.

Just idea: Can you please monitor voltage levels during connection to MCU. You used supervisory circuits monitor at 4.63V and week power supply can theoretically caused some issue.

Could you please provide me complete name of your MCU include maskset (like MC9S12D64CPVE 4L86D)?


0 Kudos
2,637 Views
thommes
Contributor III

Ok, I'm back with new testings made and new informations.

1) I connected BKGD to GND and messured ECLK. I saw just 5V and i thought a frequency should me measured or am i wrong? So what does this mean?

2) I Monitored Vddr, Vddx and Vdda -> all stay at 5V while reset and after.

3) THe MCU decsription is: MC9S12D64 - MPVE -0M89C - QQNW1018

4)I attached a file where you can see Reset and BKGD line when i start the NoIce-communication (or try to communicate...)

The green channel is Reset.

The yellow channel is BKGD.

I made the same with the CardS12 module from Elektronikladen and had a look on the communictaion.

There is more communication, which seems to be like the 4 spikes i see in the attached file, is like a "hello MCU are you there?" But there is no answer from the MCU so the "handshake" fails. Right?

Also for you, i am really thankful that you spend your time trying so solve my problem. Thanks you two very very much

0 Kudos
2,637 Views
RadekS
NXP Employee
NXP Employee

Your MCU is probably secured. For unsecure, you should do Complete mass erase by BDM device(in special mode). Unfortunately I don’t have experience with NoICE debugger tool.

In CodeWarrior debugger menu ->MultilinkCyclonePro->Unsecure…

If not work you can use unsecure12 from P&E (In case when you using BDM tool from P&E):

http://www.pemicro.com/downloads/download_file.cfm?download_id=16

Unsecure_12 Help Files:

http://www.pemicro.com/downloads/download_file.cfm?download_id=14

Note: For downloading is necessary registration.


0 Kudos
2,637 Views
thommes
Contributor III

Right now i am downloading CodeWarrior. Can i use CodeQarrior in combination with a ComPod Debuginterface?

0 Kudos