Hello,

I'm a novice in this field.
I'm trying to synchronize a 68HC11E1 from homemade circuit, using JBUG11 with an FTDI (USB/UART) interface based on an FT232R.

Limited in equipment (basic multimeter and Arduino UNO R3), I've confirmed that the talker signal emitted by JBUG11 to the RAM is correctly addressed to the PD0/RX pin of the 68HC11 (using the Arduino and RealTerm).

The problem seems come from the clock, which is clocked by an 8MHz crystal with a 10MOhm resistor between XTAL and ETAL and two 23pF capacitors
to ground, according to the manufacturer's specifications.

My measurements are:

XTAL = 2.43V
ETAL = 1.44V
EClock = 2.8mV
RESEToff = 4.97V
RESETon = 0V
MODA = 0V
MODB = 0V

I don't understand what's forbid the Eclock output from emitting its square wave signal and therefore displaying 2.5V on the multimeter.

Does anyone have experience developing an interface for this type?

 

Hello,

I'm a novice in this field.
I'm trying to synchronize a 68HC11E1 from homemade circuit, using JBUG11 with an FTDI (USB/UART) interface based on an FT232R.

Limited in equipment (basic multimeter and Arduino UNO R3), I've confirmed that the talker signal emitted by JBUG11 to the RAM is correctly addressed to the PD0/RX pin of the 68HC11 (using the Arduino and RealTerm).

The problem seems come from the clock, which is clocked by an 8MHz crystal with a 10MOhm resistor between XTAL and ETAL and two 23pF capacitors
to ground, according to the manufacturer's specifications.

My measurements are:

XTAL = 2.43V
ETAL = 1.44V
EClock = 2.8mV
RESEToff = 4.97V
RESETon = 0V
MODA = 0V
MODB = 0V

I don't understand what's forbid the Eclock output from emitting its square wave signal and therefore displaying 2.5V on the multimeter.

Does anyone have experience developing an interface for this type?

From your images it looks like you have a 2.2 Megohm resistor across the Crystal and 2 off 22nF capacitors to Gnd instead of a 10M and 22pF capacitors!

 

I can assist with the 68HC11 as I have a lot of experience with MC68HC811E2FN and MC68HC711E9CFNE2.

I am sorry to say, when working with MCU embedded systems development, you really need to have an oscilloscope.

What are you hoping to accomplish?

 

about https://www.nxp.com/products/68HC11E1 [Documentation] . . . [Show All]

about XTAL osc https://www.nxp.com/docs/en/application-note/AN1706.pdf
about XTAL osc setup https://www.nxp.com/docs/en/application-note/AN1783.pdf
benefit optional/NuLL → https://www.nxp.com/docs/en/data-sheet/M68HC11E.pdf#page=156
benefit optional → https://www.nxp.com/docs/en/reference-manual/M68HC11RM.pdf#page=377
? https://www.nxp.com/docs/en/engineering-bulletin/EB396.pdf ? hints that the output drive level of XTAL is "non-std." for expected digital output

 

Hello everyone, and thank you again for feedbacks.

I'm well aware that not having an oscilloscope makes things more complicated.

Regarding the photo, I did indeed change the resistor.

I'm working on the reset circuit.

I added a 1µF capacitor in parallel with the reset switch and reviewed all the literature I've gathered on the 68HC11 regarding this.

There are a few possibilities for timing control using M34164/M34064, DS1233, TA7523, HC14/HC4066, and even 2N3904 transistors, in addition to those you mentioned.

I'm going to run some tests.

If it doesn't work, I think I'll keep using an oscilloscope.

Regards

 

The value of the resistor across the crystal's pins is not that critical - any value between 1 and 10 M should do. But the capacitances should be in the pF range (22 pF is expected to work) !
And - funny! - the resistor should be close to the µC while the capacitors should be close to the crystal !

P.S.: Your multimeter might measure 2.5 V (@ 5V Vcc) even when the circuit is oscillating. Although oscillations might stop as well when the multimeter is connected.

 

Did you check those "22pF" Orange capacitors? They definitely look like 0.022uF (22nF) to me!

 

Did you check those "22pF" Orange capacitors? They definitely look like 0.022uF (22nF) to me!

i guess i have seen some HV reddish-orange pF range caps . . . also the physical size at today's market has a broad range
which necessary does not mean anything for this particular case

 

Hello,

Thank you for your insightful feedback.

Sorry for my absence; unfortunately, I have to address this issue intermittently, which may explain it.

After a complete check of the circuit, including replacing the 22pF capacitors (which were faulty – components I had desoldered), I finally managed to establish communication. For the reset, I kept a 1µF capacitor in parallel with the manual switch and I'm using a 74LS14N to control a CD4066BE switch, based on a Motorola EVBU schematic and the components I had on hand, to improve synchronization.

The stability isn't 100% reliable yet, but it did allow me to verify the .S19 addressing scheme and perform some EEPROM dumps.

This, in a way, "validates" this prototype card, queried via JBUG11 on a TMP68HC11E1T.

However, I tried it on a TMP68HCP11A1WT from the faulty ECU of my old classic car that I'm trying to repair, and I was surprised to find that the EEPROM was empty, as was the ROM.

Attached the JBUG11 log and the EEPROM

RESET
Booting talker to RAM
Talker bytes echoed:
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
0000 F8 8E 00 ED CE 10 00 6F 2C CC 30 2C A7 2B E7 2D .......o,.0,.+.-
0010 86 40 06 7E 00 12 B6 10 2E 84 20 27 F9 B6 10 2F .@.~...... '.../
0020 43 8D 46 2A 51 8D 33 8F 8D 30 17 8D 2D 8F 81 FE C.F*Q.3..0..-...
0030 26 0D A6 00 8D 33 17 8D 21 16 08 5A 26 F4 3B 81 &....3..!..Z&.;.
0040 BE 26 16 17 8D 14 E7 00 18 CE 00 01 18 09 26 FC .&............&.
0050 E6 00 F7 10 2F 08 4A 26 EB 27 3F 2E C5 0A 26 A0 ..../.J&.'?...&.
0060 C4 20 27 F5 F6 10 2F 39 18 8F B6 10 2E 2A FB 18 . '.../9.....*..
0070 8F B7 10 2F 39 81 7E 26 0C 30 8F 8D EB 17 8D E8 .../9.~&.0......
0080 30 C6 09 20 AC 81 3E 26 12 8D CE 17 8D CB 8F 35 0.. ..>&.......5
0090 86 09 20 AF 86 4A 8D D0 0E EA 81 4A 26 B9 30 C6 .. ..J.....J&.0.
00A0 09 3A 35 EC 07 8D C0 17 8D BD CC 00 98 ED 07 20 .:5............
00B0 C7 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00C0 00 00 00 7E 00 15 7E 00 58 7E 00 58 7E 00 58 7E ...~..~.X~.X~.X~
00D0 00 58 7E 00 58 7E 00 58 7E 00 58 7E 00 58 7E 00 .X~.X~.X~.X~.X~.
00E0 58 7E 00 58 7E 00 58 7E 00 58 7E 00 58 7E 00 58 X~.X~.X~.X~.X~.X
00F0 7E 00 58 7E 00 94 7E 00 00 7E 00 58 7E 00 FF ~.X~..~..~.X~..
Using RAM based talker on COM1
SV B600 B7FF "[MyDocs]\ECU_LT\Dump7\EEPROM.S19"
Saving complete
V "[MyDocs]\ECU_LT\Dump7\EEPROM.S19"
Memory verifies OK
SV B600 B7FF "[MyDocs]\ECU_LT\Dump7\EEPROM.bin"
SV BF00 BFFF "[MyDocs]\ECU_LT\Dump7\ROM.S19"
Saving complete
V "[MyDocs]\ECU_LT\Dump7\ROM.S19"
Memory verifies OK
SV BF00 BFFF "[MyDocs]\ECU_LT\Dump7\ROM.bin"

I can't explain why the ROM is also empty.

It should normally contain some basic commands, if I understand the Motorola documentation correctly?

In short, further investigation is needed.

Regards,

 

Code protection likely on the rom and eeprom.