topic Re: Update: in 8-bit Microcontrollers

MC9S08QGx + PTA4 dead

irob — Tue, 13 Feb 2007 00:06:31 GMT

I have a problem that's similar to this tread, except my PTA4 pin is dead in hardware, not simulator. More like this thread.

I've found the part of the datasheet that mentions the Background Debug Mode Pin enable in the SOPT1 register. But I still can't toggle that pin.

Any other registers I've missed?

Message Edited by irob on 2007-02-1209:08 AM
Alban edited part number

Message Edited by Alban on 2007-02-12 05:51 PM

Re: 9S08QGx + PTA4 dead

Alban — Tue, 13 Feb 2007 00:23:15 GMT

Hello Rob,

I don't think S08QB8 exists. Can you please either modify the thread title or post a reply with correct reference and I'll update.

HC908QB8 or 9S08QG I imagine

Cheers,

Alban.

Message Edited by Alban on 2007-02-12 05:51 PM

Re: 9S08QGx + PTA4 dead

irob — Tue, 13 Feb 2007 00:32:43 GMT

Done.

Message Edited by Alban on 2007-02-12 05:51 PM

Re: HC908QBx + PTA4 dead or S08QG

Alban — Tue, 13 Feb 2007 01:23:52 GMT

Sorry to bother you again irob, but QB does not exist in the S08 family.

I sound boringly insistant, but that difference is necessary for me to see your issue.

If it has BDM it is S08QG8, if it has MON08 it is HC908QB8.

Cheers, Alban.

Re: HC9S08QGx + PTA4 dead

irob — Tue, 13 Feb 2007 01:34:56 GMT

My mistake (again!) I'm using the QG. But I'm not able to edit that first post anymore, not sure why. Thanks,

Re: 9S08QGx + PTA4 dead

Alban — Tue, 13 Feb 2007 01:50:21 GMT

Posts can only be edited with 2 hours of posting. I am doing it, no prob :smileywink:

Re: MC9S08QGx + PTA4 dead

Alban — Tue, 13 Feb 2007 03:55:08 GMT

Dear irob,

I've seen a post from Petr stating he saw a mistake in the simulator and not in hardware.

Is there a remote possibility you've drawn too much current from the I/O and burnt it ?

A trick on I/Os and how to read levels:

- If the Data Direction Register (DDR) says input, when you read the Port (PTx), it will return the status of the pin.

- If the DDR is output, reading PTx returns the content of the register PTx and not the status of the pin.

Have you tried with another MCU to check ?

Cheers,

Alban.

Re: MC9S08QGx + PTA4 dead

irob — Tue, 13 Feb 2007 04:06:43 GMT

Hmm, well I just verified that PTA4 works on my DEMO9S08QG8 board.

The problem with my target that isn't working is that PTA4 is also the Background pin. This is probably why I can't single step this and see it happening.

It's not possible that I drew too much power. It's an I2C clock line on my target. I don't even have the I2C peripheral in place, just a scope to watch the lines working.

Re: MC9S08QGx + PTA4 dead

Alban — Tue, 13 Feb 2007 04:37:02 GMT

Hey again,

May be the MCU is 'frozen'. I don't know if you are certain it is still running with other activity.

When you have a reset and BKGD pin low, you force the MCU to start in Special Single Chip Mode (SCC).

It's another supposition to check by leaving PTA4 floating and see it's level.

Anyone else has any idea ?

Cheers,

Alban.

Re: MC9S08QGx + PTA4 dead

petr — Tue, 13 Feb 2007 16:44:08 GMT

Hello irob
Since you are using the PTA4 as I2C clock, do you have an external pull-up there? Maybe this pull-up is causing your problems.
Petr

Re: MC9S08QGx + PTA4 dead

irob — Wed, 14 Feb 2007 06:57:10 GMT

True, I do have a 3.3K pullup on PTA4, but it's for the Background pin. Please realize that I'm unable to toggle that pin to 0 when configured as an output.

Update:

irob — Sat, 17 Feb 2007 07:59:50 GMT

Well, something else must be wrong with my original firmware.

I've made the following real simple test code:

for (;
{
__RESET_WATCHDOG(); // Kicks the dog
PTAD_PTAD4 = 1;
LED_RED = ON;
Delay (20000);
PTAD_PTAD4 = 0;
LED_RED = OFF;
Delay (20000);
}

And this works nicely, so I've got to go back to the drawing board.

Re: Update:

irob — Wed, 21 Feb 2007 07:29:50 GMT

So strange. I'm unable to duplicate my last post today. PTA4 is no longer working again. I think I may have been looking at PTA3 by accident.

Alban wrote:

May be the MCU is 'frozen'. I don't know if you are certain it is still running with other activity.

When you have a reset and BKGD pin low, you force the MCU to start in Special Single Chip Mode (SCC).

It's another supposition to check by leaving PTA4 floating and see it's level.

Here is my setup: I have this target board with a couple LEDs on Port B. I have some very simple test code running right now:

SOPT1_BKGDPE = 0;
PTADD_PTADD4 = 1;
PTADD_PTADD3 = 1;

for (;
{
__RESET_WATCHDOG();
PTAD_PTAD4 = 1;
PTAD_PTAD3 = 1;
LED_RED = ON;
Delay (20000);
PTAD_PTAD4 = 0;
PTAD_PTAD3 = 0;
LED_RED = OFF;
Delay (20000);
}

After programming, I remove my BDM cable, so as not to affect the above function. I see my LED toggle nicely, so I know that the program is alive. I also have PTA3 and PTA4 on a scope. Only PTA3 toggles. PTA4 comes up out of POR high, full 3.3V. I'm still unable to drive PTA4 low ever.

Re: Update:

bigmac — Wed, 21 Feb 2007 10:46:34 GMT

Hello iRob,

Have you already eliminated the possibility that the device in the target is faulty? Do you get identical behavior with different MCU samples in your target? Does the test code work OK in the demo board?

Regards,

Mac

Re: Update:

irob — Sat, 24 Feb 2007 01:44:46 GMT

Ok, I've just fired up a second target board with the same above code. I've got PTA4 on the scope and out of POR, it's driven high. Again, this target also has the 3.3K pullup on PTA4. But I refuse to believe that this MCU can't drive that low at all.

There's got to be something fundamental I'm not doing. I thought for sure that the SOPT1 setting would fix this, but it hasn't.

Is there something else I should be doing? Good grief, one of those weeks for me.

Re: Update:

irob — Sat, 24 Feb 2007 04:22:25 GMT

Hmm, more straneness. In my post #12 above, I noted that that simple test code worked. I'm unable to reproduce this now, which leads me to wonder if maybe I had left the BDM connector on my target while testing. When running the debugger, it would have appeared to be working, since the BDM interface does in fact toggle PTA4 (Background pin) while running to communicate with the target.

With the BDM disconnected, there is no activity on PTA4 though my test code should be.

The following code is a modified version to work with a switch:

PTADD_PTADD4 = 1; // make PTA4 output
PTADD_PTADD3 = 1; // make PTA3 output

MINUS_DDR = 0;
MINUS_PUE = 1;
PLUS_DDR = 0;
PLUS_PUE = 1;

for (;
{
__RESET_WATCHDOG(); // Kicks the dog
if (MINUS == CLOSE)
{
PTAD_PTAD3 = 0;
PTAD_PTAD4 = 0;
LED_RED = ON;
}

else
{
PTAD_PTAD3 = 1;
PTAD_PTAD4 = 1;
LED_RED = OFF;
}

With each switch press, I see PTA3 toggle on the scope, PTA4 does not. I verify this behavior on both my target and my DEMO9S08QG8.

Re: Update:

peg — Sat, 24 Feb 2007 20:10:28 GMT

Hi Rob,

Thought I would take a quick look at your little problem here.

Started with a simple programme from the Quick start examples (GPIO)

This just echoes two inputs to two outputs.

Loaded this into my homebrew DemoBoard

Works!

Added some lines to disable BKGD pin, enable PTA4 as an output and then just switch it along with one of the existing led outputs.

Well! what I find is the instant I disable the BKGD function (before enabling it as an output) the pin goes low (0.04V) and there it stays forever (even though there is an external 3k3 pullup there). The other function for this pin (ACMPO) should be disabled out of reset.

Well I found a problem with PTA4! But got the opposite result to you.

Needs further investigation....

Re: Update:

peg — Thu, 29 Oct 2020 08:46:17 GMT

Hi,

Well, the only problem was me being in a hurry. I was trying to manipulate PTB4 instead of PTA4.

It work perfectly now.

The instant drop to 0V is normal because A4 is always an output as soon as the other higher priority functions are disabled and as PTA is cleared on POR you get low.

Here is my test programme in assembler, the mistake was revealed when I converted it from C.

Code:

$Include "mc9s08qg8.inc" org RomStartstart mov #%11000000,PTBD  ;turn off LED's mov #%11000000,PTBDD ;make outputs mov #%00010000,PTAD  ;make GPIO on BKGD pin high mov #%00010000,PTADD ;set to output (not required, always output) lda #%00001100 sta PTAPE   ;pullup two switches lda #$D0 sta SOPT1   ;disable BKGDloop sta SRS   ;feed the dog brclr 2,PTAD,loop5  ;test switch 1 bset 6,PTBD   ;turn off LED1 bra loop10loop5 bclr 6,PTBD   ;turn on LED1loop10 brclr 3,PTAD,loop15  ;test switch 2 bset 7,PTBD   ;turn off LED2 bset 4,PTAD   ;set GPIO on BKGD pin bra loop20loop15 bclr 7,PTBD   ;turn on LED2 bclr 4,PTAD   ;clear GPIO on BKGD pinloop20 bra loop  org Vreset DW start  ;reset vector

This will run directly on a DEMOQG8

I enclose the s19 if you just want to drop it straight in to try it.

Re: RESOLVED in C

irob — Fri, 16 Mar 2007 04:05:55 GMT

Thanks for the help, Peg. I just now found the time to give this a try.

I tried your bit file and sure enough, it works. That's a relief that I didn't kill my DEMO board! In your program, SW1 only turns on LED1, nothing else. Was that to throw me off?

In looking through your code, I noticed that you allocated the SOPT register all at once. I had been doing it bitwise in C as such:

SOPT1_COPE = 1; // COP enabled
SOPT1_BKGDPE = 0; // Change PTA4 from Background mode to output pin

I read in the datasheet on page 68, that SOPT is a

"write-once register so only the first write after reset is honored... Any subsequent attempt to write to SOPT1 (intentionally or unintentionally) is ignored to avoid accidental changes to these sensitive settings."

This explains why my code wasn't working. I had two write attempts in my code. I've replaced those two lines with:

SOPT1 = 0b11010000;

This now works fine. PTA4 is alive, hurray! But this leads me to a certain amount of frustration with Freescale's C header file for the MC9S08QG8. They have a structure defined for all the individual bits in the SOPT1 register. Those are fine to use if you are only writing that one bit in the whole register. Note to self: read the datasheet for every register!

Re: RESOLVED in C

bigmac — Fri, 16 Mar 2007 10:01:59 GMT

Hello iRob,

The structure, within the header file, defining the individual bits of SOPT1 is still useful if you need to test the status of a particular bit. I guess it is included on that basis.

I agree that you just have to learn which registers have special characteristics, and check the documentation during the programming process. Even the experts can overlook this sort of thing - I recently discovered some code within an application note that attempted to separately set each bit in a write once register.

Regards,

Mac