PortD[3] on the MC1321x

[RedMountain]

I am developing using the MC1321x series of 8-bit microcontrollers, specifically the MC13213 at this time. I have encountered a problem with this new System in Package, in that I have been unable to successfully reset the modem from the MCU. One of the most puzzling things is my inability to program PortD[3], tied to ~M_RST (or ~M_RSTB) on the modem, as an output. To quote from data sheet MC1321xRM, section 3.4.1.2:

"From a reset condition, the MCU initiates PTD3 as a high-impedance input with the internal pull-up disabled. As a result, the modem reset input will be floating and the modem will not be held to reset. As part of the MCU initialization PTD3 must be programmed as an output and then driven low to reset the modem. The ~M_RST input is asynchronous and needs to be held low for only a short period."

Programming PTD3, a pin that is not output from the package but is merely an inner connection between the modem and HC(S)08 series MCU, as an output resets the microcontroller while running in debug and displays ILLEGAL_BP. The problem does seem to be with this specific pin, as I have used other pins to blink LEDs, and have even programmed another internal pin, PortD[1] (RXTXEN), as output with no problems. Other pins on PortD are functional.

Because it seems odd to me that this GPIO pin would be useful for anything other than resetting the modem, as access to the output is impossible, I thought that perhaps initialization of this particular pin of the port wouldn't need initialization, and was simply an output after reset, and forevermore after that. Even though this doesn't agree with the documentation that I have seen, I tried pulling ~M_RST low for a second, and then released it. Then, I waited for the IRQ interrupt that should arrive from the modem within 25 ms of reset (section 9.1.1 of MC1321xRM), but nothing. I didn't really expect anything, but it was worth a try.

Any ideas?

[rocco]

Hi, Red, here are a couple of unlikely ideas:

Did you set PortD[3] low prior to setting it as an output? Have you tried setting it high instead? The reasoning, in my meager mind, would be to see which step is causing the problem: making PortD[3] an output, or reseting the modem. I would guess that it's reseting the modem, but we need to verify.

What does your firmware do after it resets the modem? Do you have the watchdog timer disabled? Could reseting the modem cause your firmware to hang in a place where it fails to keep the dog happy?

[RedMountain]

Thanks for the ideas, Rocco. It unfortunately never gets far enough to even send the reset pulse to the modem. I tried your suggestions - I had been disabling the watchdog timer right after port directions were set, so I tried moving the port init after the watchdog disable, but that didn't change anything. I haven't been touching the port until after I (attempt to) initialize directionality, other than my previously mentioned attempt to just drive PortD[3] low and then releasing it high to see if initialization was even necessary. I tried this again, but drove the pin high first this time. Like the first time, the commands are executed, but the IRQF flag in IRQSC isn't set like I am expecting. If I don't try to initialize directionality on PortD[3], the chip doesn't reset, but just hangs at a while loop I have waiting for the interrupt flag to be set.

while(!IRQSC_IRQF); // wait for modem interrupt

Here's where it resets with ILLEGAL_BP:

// Port Direction
PTADD = 0xFF; // Port A output
PTCDD = 0xFF; // Port C output
//PTDDD = 0xFF; // Port D output
//PTDDD_PTDDD0 = 1;
//PTDDD_PTDDD1 = 1;
//PTDDD_PTDDD2 = 1;
=> PTDDD_PTDDD3 = 1; // ~M_RST as an output

It crashed when trying to set the entire port, so I tried individual bits. It crashes on PortD[3].

I've been using a device header for the MC9S08GT60, since I haven't seen a header for the MC1321x processors in CodeWarrior. I thought maybe the registers had been switched and that may cause difficulty, but the header initializes PTDDD at address 0x000f, which agrees with the MC1321x documentation (MC1321xRM, pg. 11-4). Too bad. I thought I had figured it out.

[RedMountain]

A few additional things:

I have set the IRQ Pin Enable bit.

IRQSC_IRQPE = 1; // enable irq pin function

Also, _PTDD.Bits.PTDD3 is set, regardless of what I write to it.

[RedMountain]

Ok, a few more developments. Maybe some of you will have a better idea of what is going on.

It seems that setting a pin as output that is connected to PortD[3] and ~M_CLR also generates an ILLEGAL_BP in the debugger. I tried wiring PortD[2] (a normal unused I/O port not in contact with the modem) to the test point associated with PortD[3]/~M_CLR, and when I try setting that as an output, same error. If I move the connection from PortD[3] to something else (like an LED), PortD[2] initializes correctly as output, and the code executes properly. Identical code in both cases, with one failing.

Does anyone know of something that would cause a processor to reset on setting a pin as output? Any other help would also be appreciated.

[RedMountain]

Okay, we have finally made progress; and what results we have, my friends! Thinking that there definitely seemed to be something hardware related to my problem, since the problem would migrate as I connect other pins and subsequently set them as outputs, I played with it a bit more. I tried manually pulling the modem ~reset low by shorting the appropriate test pin (Pin 71 on the MC1321x) to ground. Strangely enough, the debugger died, saying that the MCU reset was being pulled low. By finding that out, and a bit more playing and using my powers of deduction, I was able to get the processor to initialize correctly, and even get an interrupt from the modem, presumably meaning the modem is working correctly (I have yet to do any work with it yet after figuring this out). To get it to work, I set the corresponding bit in the PortD data register so that the line would be held in the not reset position. Then, I could set the pin as output without a problem.

In other words, the modem reset is tied to the entire processor's reset, and by pulling the pin low (or initializing the port as output without first setting the data register) I was effectively executing a hard reset in software. This pin was acting like a big red self-destruct button that I ritualistically pushed during processor initialization.

Now, the questions. Why? To again quote the documentation that I quoted in my original post,

"From a reset condition, the MCU initiates PTD3 as a high-impedance input with the internal pull-up disabled. As a result, the modem reset input will be floating and the modem will not be held to reset. As part of the MCU initialization PTD3 must be programmed as an output and then driven low to reset the modem. The ~M_RST input is asynchronous and needs to be held low for only a short period." -MC1321xRM, section 3.4.1.2

It doesn't make sense to me that the documentation would be so incredibly wrong, or that the modem reset would be tied to the processor reset. I thought it might be attributed to bad soldering, but the pins in question are on opposite sides of the chip - there would be plenty of other places that would short before those particular pins would short. _However,_ further examination of the underside of a board located a via just barely shorted to a trace, connecting the ~RESET and ~M_RST networks. Problem solved.