MC9S08QGx + PTA4 dead

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

MC9S08QGx + PTA4 dead

4,511 Views
irob
Contributor V
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

Labels (1)
0 Kudos
20 Replies

1,142 Views
Alban
Senior Contributor II
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.
0 Kudos

1,142 Views
irob
Contributor V
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.
0 Kudos

1,141 Views
petr
Contributor I
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
0 Kudos

1,141 Views
irob
Contributor V
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.
0 Kudos

1,142 Views
irob
Contributor V
Well, something else must be wrong with my original firmware.

I've made the following real simple test code:

for (;:smileywink:
{
__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. :smileyhappy:
0 Kudos

1,142 Views
irob
Contributor V
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 (;:smileywink:
{
__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.
0 Kudos

1,142 Views
bigmac
Specialist III
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
 
0 Kudos

1,142 Views
irob
Contributor V
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. :smileysad:
0 Kudos

1,142 Views
irob
Contributor V
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 (;:smileywink:
{
__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.
0 Kudos

1,142 Views
peg
Senior Contributor IV
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....
 
0 Kudos

1,142 Views
peg
Senior Contributor IV
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.
 
0 Kudos

1,142 Views
irob
Contributor V
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? :smileywink:

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!
0 Kudos

1,142 Views
bigmac
Specialist III
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
 
0 Kudos

1,142 Views
Alban
Senior Contributor II
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.
0 Kudos

1,142 Views
Alban
Senior Contributor II
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

0 Kudos

1,142 Views
8_BitMCU
Contributor I
S08QB8 was not available but it is available now since 6 Jan 09.. It is freescale's new low cost low power MCU. Please visit following for more info:
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=S08QB&nodeId=01624684491437
0 Kudos

1,142 Views
irob
Contributor V
Done.

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

0 Kudos

1,142 Views
Alban
Senior Contributor II
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.
 
0 Kudos

1,142 Views
irob
Contributor V
My mistake (again!) I'm using the QG. But I'm not able to edit that first post anymore, not sure why. Thanks,
0 Kudos

1,140 Views
Alban
Senior Contributor II
Posts can only be edited with 2 hours of posting. I am doing it, no prob :smileywink:
0 Kudos