MC68HC16Z1 P&E Micro Debugger Issue

[MikeBrennan]

Have a question from Schneider:

Here is a description of the issue that the team has.

Configuration:

MCU: MC68HC16Z1, specific PN: MC68HC16Z1CEH16.

Flash: AMD29F400B or equivalent.

P&E Micro debugger: Multilink FX

P&E Micro software: PROGG16Z and ICD16Z

Issue:

P&E Micro debugger cannot enable BDM and program blank flash chip of MC68HC16Z1, but it can enable BDM and program flash chip with bootloader (sector 0).

Note:

P&E Micro debugger can enable BDM and program blank ship chip using its own development board with MCU MC68HC916X1.

Observations:

Waveform measured on reset pin shows at this condition: MC68HC16Z1 + Blank Flash Chip (all ‘FF’), a narrow reset pulse of 60us appears on reset line every 15-16ms.

Possible interpretation:

MCU/CPU is reset by default watchdog setting comes out of reset, time-out period is 15.6ms.

I do see when P&E Micro debugger attempts to enable BDM, reset line is indeed pulled low for about 20ms, but CPU freeze pin never go up high. BKPT remain low (set by debugger) all the time.

We cannot see circuits of board causing the periodic reset. Reset pin is connected to a few chips, but none can seems produce this issue.

We hope the summary can provide a background of the problem, and NXP technical analysis and assistance are appreciated.

[lama]

Hi,

He MCU is really old and we already do not have resources for it. However….

MCU+Blank chip and executed is nothing…. OK, if the  MCU is in the BDM mode then it stops and reset should not appear. However if you leave it in normal mode then it executes it loads reset vector FFFF and jumps to this address to execute the code at this address … I suppose nothing good will be executed and it will  jump into some of the resets.

Of course reset status of the SW WDT is enable by default SYPCR_SWE=1, Software watchdog clock is not prescaled and divide ratio of clock is 2^9, MODCLK=?

So, you are able to do reverse calculation whether the reset is caused by WDT or it is another source. (5.4.5 Software Watchdog)

The programming procedure must correctly set MCU into the BDM mode after reset when it stops and wait for BDM commands.

The issue can be in the BDM connection. From my experience… incorrectly connected BDM cable, malfunctioned BDM cable, wrong/old BDM routines – old drivers, not compatible BDM or multilink with the operating system.

I would suggest you to contact www.pemicro.com support as a manufacturer of the BDM interface and programming tool.

One of the things we usually do is that we try to test connection on more boards, usually some older which is confirmed working with correct design and the new one.

Best regards,

Ladislav