We have been using the 68LC302 for decades without major problems. We have designed a new product using the same circuitry around the 68LC302 as before but we can't get it to serial boot. PA5, PA7, PA12

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

We have been using the 68LC302 for decades without major problems. We have designed a new product using the same circuitry around the 68LC302 as before but we can't get it to serial boot. PA5, PA7, PA12

Jump to solution
707 Views
dos
Contributor I

We have been using the 68LC302 for decades without major problems. We have designed a new product using the same circuitry around the 68LC302 as before but we can't get it to serial boot. PA5, PA7, PA12 & DISCPU are all low for serial boot but it won't echo data sent to SCC1. The clock is running correctly but the CPU resets every ~4.2uS, with internal activity seen on /DTACK synchronous to this. It isn't the MAX691A reset chip, the reset pulses are from the CPU. We have built 2 prototypes and both behave the same. We've been checking this from every angle for days. Help!

0 Kudos
1 Solution
562 Views
TomE
Specialist II

It sounds like it isn't resetting properly. Either it isn't seeing PA7 pulled low or the CPU Reset isn't working properly. Are you sure both RESET and HALT are being driven for the required time?

The 4.2us |cyclic reset" looks like the Bus Monitor going off. That implies it may be trying to boot from an external ROM. Are any of the other memory signals being driven?

 I would suggest going through the schematic again. Make sure all the power pins are connected properly.There may be a mistake converting the schematic to the PCB layout, so I'd validate the layout by visually following every pin connection referenced to the pin names in the Reference Manual. That's on the PCB Layout, not the Schematic.

Are you using PGA or TQFP? You're lucky you're not using BGA, so you can get an oscilloscope onto every pin on the chip. and verify the levels and clocks.

Given you have a previous working product, get an old and new one side-by-side and then wire them into "permanent reset" with the POR chip driving both RESET and HALT. Then compare every pin between the good and bad boards, looking for differences. If that doesn't show anything, rig an oscillator to cyclically reset both boards, and then compare the pins at different times during the reset cycle, looking for differences.

Tom

View solution in original post

3 Replies
562 Views
dos
Contributor I

Thank you very much for solving this. PA7 was held low at 0.385V by a jumper in a 120k/10k resistor divider to +5V but this wasn't low enough, despite VLmax = 0.8V in the data book. 120k/1k worked and we will optimize later. In previous circuits we didn't use PA7 so we jumpered it to ground for serial boot, which always worked.

0 Kudos
563 Views
TomE
Specialist II

Congratulations on finding this.

0.385V is the theoretical voltage for 120k/10k from 5V. Did you actually measure the voltage on that pin, both normally and during reset?

There might be an undocumented pullup on that pin, possibly only enabled during RESET that was pulling the voltage above the threshold. You could detect this by measuring the voltage on that pin with your previous resistor setup. You should be able to measure any shift with your current setup too.

PA7 (and other pins) have Schmitt Trigger inputs. The hysteresis and the levels are not documented in the Reference manual. That might have shifted the input level to lower than documented, or it may be that the Schmitt is implemented with a resistor back to the input pin.

The input pin leakage is specified at 20uA. That could develop 0.2V across your 10k resistor. That plus 0.385 is still well short of the 0.8V specification through.

Tom

0 Kudos
563 Views
TomE
Specialist II

It sounds like it isn't resetting properly. Either it isn't seeing PA7 pulled low or the CPU Reset isn't working properly. Are you sure both RESET and HALT are being driven for the required time?

The 4.2us |cyclic reset" looks like the Bus Monitor going off. That implies it may be trying to boot from an external ROM. Are any of the other memory signals being driven?

 I would suggest going through the schematic again. Make sure all the power pins are connected properly.There may be a mistake converting the schematic to the PCB layout, so I'd validate the layout by visually following every pin connection referenced to the pin names in the Reference Manual. That's on the PCB Layout, not the Schematic.

Are you using PGA or TQFP? You're lucky you're not using BGA, so you can get an oscilloscope onto every pin on the chip. and verify the levels and clocks.

Given you have a previous working product, get an old and new one side-by-side and then wire them into "permanent reset" with the POR chip driving both RESET and HALT. Then compare every pin between the good and bad boards, looking for differences. If that doesn't show anything, rig an oscillator to cyclically reset both boards, and then compare the pins at different times during the reset cycle, looking for differences.

Tom