68LC302 and serial bootstrap feature

tomstorey

Hi all. Hopefully there is still someone around in 2026 that has some knowledge tucked away in the back of their brains regarding the LC302.

I've been working on a little project involving an LC302 and I am interested in using the serial bootstrap feature. I just cant seem to get it to work and I wondered if there is anything particularly special that needs to be done to make it work.

I've tried everything I can think of, and I'm currently looking at replacing the LC302 that I currently have in case it is somehow faulty, but thought I'd ask the question before I go to that effort. FWIW the markings on the package are (with Motorola logo):

MC68LC302PU25CT
2J29A
QQDJ0316

I am powering it with 5V.

Basically I cannot get it to echo back anything that I am sending to it. I came across the following post which seemed to describe the same problem, but I dont seem to have the same issue: https://community.nxp.com/t5/ColdFire-68K-Microcontrollers/We-have-been-using-the-68LC302-for-decade...

Things I've tried/I can observe with my scope/logic analyser:

I've tried using both PLL mode and not. In PLL mode I used a 4MHz oscillator (4.192 is hard to come across). In this mode I used 9174 baud (4MHz*4, /109, /16). Without the PLL I used a 20MHz oscillator with baud 11467. I've used my signal generator to feed 4.192MHz in and used the baud rate quoted in the datasheet also to no avail.

If I pull PA7 high to disable bootstrap mode, I can observe some brief activity on the AS pin, presumably as the CPU tries to read its reset vector from external memory. If I pull PA7 low to enable bootstrap mode I don't observe this activity any more, presumably as the CPU is held in reset.

I did early on discover that PA7 seems to have some kind of current source on it, and was sourcing approx 3-4mA of current (measured with my multimeter in current mode), overpowering my external pull down resistor and resulting in a logic high. This feels like an extremely high amount of current to me, and does anyone have an explanation for that? It seems vaguely related to the above thread causing PA7 to be pulled too high unexpectedly. Maybe my part is faulty?

Reset and HALT are being asserted simultaneously (I've got lots of 68k experience from hobby projects over the past several years).

I've double and triple checked all of my wiring including the polarity of the TX/RX signals, and even pulled the flow control inputs for SCC1 to their negated state just in case. I've measured with my oscilloscope that my USB-serial adapter does indeed generate the baud rate that I am requesting, and looping TX to RX allows me to echo back the characters that I send in putty, so I am fairly confident there is nothing odd going on there.

I havent wired up any of the memory busses, because for now I am just interested to see if I can load some code in via serial and make an LED blink, but the BUSW pin has been strapped for 16-bit bus operation, if that matters?

Does anyone have any other suggestions before I go desoldering stuff?

Thanks!

tomstorey

So, I replaced the 68LC302 for another one, and for about 2 seconds it worked (echoed back the characters I was sending it), until I power cycled it, and from then on it wouldnt work any more again.

Initially I didnt have CD1 grounded, because the datasheet says this is a "dont care" for the purposes of the serial bootstrap process, and it did indeed work in this configuration. After it stopped working I tried grounding CD1 but this didnt help.

So close, and yet so far. This project is just cursed.

This one also seems to have some kind of heavy-ish current source on PA7 that needs a reasonably strong resistor to pull it down sufficiently, or a tri-state driver to override it.

TomE

I think you're killing the chip. There are a few ways to do that, and reading your posts suggests two possibilities.

You're running (or have run) the clock from an external signal generator. Have you terminated the cable from the signal generator so as to avoid reflections and overshoots? If you've got a 50 ohm coax from the signal generator without a 50 ohm resistor on the end, it'll glitch (the reflections) up to 10V and down to -5V. That'll kill the chip for sure.

If you have an Agilent signal generator (others might be similar), program it to "0 to 5V" and don't notice the "terminated or not" option, then setting it to terminated and not adding one will have it generate 0-10V which will then glitch to -10V to 20V. Check the clock signal at the CPU with a good (high frequency, like 100MHz or better) oscilloscope.

How are you powering the chip driving the serial port on the CPU? Do you have a MAX RS232 transceiver powered from the 5V that is powering the CPU (and being fed 12V RS232 from a PC or something)? Or are you using an external TTL-level (3V3 or 5V) serial port connected directly to the CPU? If you're using the latter then when you power the CPU off you'll still be driving that external voltage into that CPU pin. TTL-RS232 idles at 5V, so doing that might damage the pin or even cause fatal latch-up. Google says this chip can suffer fatal latch-up if you do this. Check "latch-up" on Wikipedia.

And make sure everything is grounded together. This but this is something people using CAN always forget to do. Ditto RS-232.

Tom

tomstorey

I suppose another option is to just build something properly on a PCB. I have one designed already, but I was hoping to test said design with a prototype first, before comitting to PCBs. I sort of get the feeling that if I tried to build it up on a PCB where it has a better electrical environment, maybe it would just work.

Part of the reason for wanting to prototype it was to make sure I had the correct logic for multiplexing the strapping pins between their straps and GPIOs to enter bootstrap mode during reset. The reset and bootstrap enable can be provided by some GPIOs of the MCP2221A, such that you can either do a reset on its own, or reset with bootstrap enabled.

My signal generator is a Siglent SDG2122X. When I use it I have it set to 5V peak to peak with a 2.5V offset such that it ranges from 0 to 5V, rather than -2.5 to +2.5.

My scope is a Keysight MSOX2024A, and I used that to check the signal coming from the signal gen. I wouldnt say I was using a fully optimal ground setup at the time when I did that, so I was seeing over/undershoot on the clock signal, but I'd have put that down to the fact I wasnt using a group clip or ground spring on the scope probe - I was more interested in measuring the frequency seen at the pin of the chip and just double checking the voltage was achieving 5V and not being dragged down by anything. I dont remember to what extent it was over/under shooting, I'd have to measure it again I guess.

tomstorey

Initially when I tested with the signal generator I didnt have it terminated. In the most recent case I am using an on-board 20MHz oscillator and ignoring the PLL configuration for the time being just to simplify things. (This isn't the configuration I want to run in the final version of my project (if I ever get there) though, becuase I want to use a 4MHz oscillator to drive another part as well.)

Power for the whole board is coming from a small USB-serial module from Mikroe which has an MCP2221A on it. This unfortunately has a diode in series with the 5V supply so the board sees closer to 4.7V, but I have also used a bench PSU to supply a solid 5V. I cant think of a case where the CPU would not have power but a 5V signal would be present on any of the pins - power is either there for everything or it isnt.

But if that is a situation that could result in latch-up and destroy the chip then I might just ditch the whole project now, because I am looking at building it into an arduino style board, and if these parts are just too overly sensitive to wierd and wacky power situations then they are probably highly unsuitable for this project.

Bio_TICFSL

Hello,

The first thing I would check is CD1 . For the LC302 serial bootstrap echo path, the manual says the SCC hardware echoes received characters back on TXD1 , but CD1 must be asserted; on SCC1 the external CD1 pin must be tied low . If you pulled the SCC1 modem-control inputs to their “negated” state, that may be exactly why you see no echo.

Other important points from the LC302 boot description:

Serial bootstrap is enabled by sampling PA7 = 0 during hard reset , where hard reset means both RESET and HALT asserted .
PA7 must not float; it must be deliberately pulled high or low during reset.
The first 576 bytes received on SCC1 are stored in dual-port RAM, and each received character is echoed back out of TXD1 ; the device will not leave boot mode until all 576 bytes are received.
For internal-clock bootstrap, the documented nominal clock assumptions are 4.192 MHz or 32.768 kHz , with the SCC programmed to approximately 9600 baud.
In asynchronous UART mode, the bit rate is 1/16 of the TCLK1/RCLK1 clock rate when using the external clock option.

So before replacing the part, I would try this exact minimal setup:

Hold RESET and HALT low together .
Strap PA7/BOOT low with a strong enough pulldown to overcome whatever is on your board.
Select the intended clock mode with PA5 :
- PA5 = 0 : internal boot clock mode.
- PA5 = 1 : external clock on TCLK1/RCLK1 , 16× baud.
Strap PA12/MODCLK0 consistently with the clock source; the manual samples it during hard reset to distinguish the nominal EXTAL frequency.
Tie CD1 low .
Keep RXD1 , TXD1 , RCLK1 , and TCLK1 wiring consistent with SCC1, not SCC2. The boot feature is for SCC1 in the LC302 description.
Send a full 576-byte test stream, not just one character, although the echo should appear character-by-character once receive is working.

The 3–4 mA sourced from PA7 is suspicious . The datasheet-level input leakage value retrieved is only 20 µA max , far below milliamps. Since PA7 is also a bidirectional multi-function pin, it is possible to get contention if something else is driving it or if the part has already left the reset-sampling state, but during reset-as-boot-strap it should not require sinking several mA just to read a low. I would check for a board-level pullup/driver/solder bridge on PA7 , verify the package pin orientation, and measure the current while both RESET and HALT are actively asserted.

One more practical note: your 4 MHz internal-clock attempt is not equivalent to 4.192 MHz . It may be close enough for some UARTs if the other side is adjusted, but the documented internal bootstrap mode assumes the nominal LC302 clock values, so for eliminating variables I would use 4.192 MHz with the documented baud , or use the external-clock mode and provide clean TCLK1/RCLK1 = 16 × baud .

regards

tomstorey

Hi, thanks for the message.

I have made sure that I am using SCC1 related pins.

My setup is on a perfboard with wire wrap, so there are no other influences on any of the pins other than what I have wire wrapped. I've verified with a multimeter that reset and halt are asserted together and that they reach 0V, and that all strap pins are seeing the required voltage levels with no floating pins.

Also, as mentioned in my post, I have also tried using 4.192MHz supplied by my signal generator and the baud rate quoted in the datasheet, but this didn't help.

Apologies when I said I had tied CD1 to its negated state, I've just mixed up my terminology and it is indeed tied to ground (asserted), along with CTS1 for good measure.

I'll try sending 576 bytes as a test in case it is just not echoing them back for some reason, but is still receiving them correctly.

Thanks