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!

[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:

1. Hold RESET and HALT low together .
2. Strap PA7/BOOT low with a strong enough pulldown to overcome whatever is on your board.
3. Select the intended clock mode with PA5 :
   • PA5 = 0 : internal boot clock mode.
   • PA5 = 1 : external clock on TCLK1/RCLK1 , 16× baud.
4. Strap PA12/MODCLK0 consistently with the clock source; the manual samples it during hard reset to distinguish the nominal EXTAL frequency.
5. Tie CD1 low .
6. Keep RXD1 , TXD1 , RCLK1 , and TCLK1 wiring consistent with SCC1, not SCC2. The boot feature is for SCC1 in the LC302 description.
7. 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