MC9S12DG256G not reading Port A correctly

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

MC9S12DG256G not reading Port A correctly

Jump to solution
254 Views
Chandos
Contributor I

I am trying to write an assembly language program to read a 16-key matrixed key pad using Port A of the MCU in single-chip mode.  It involves splitting Port A into 2 parts: 4 input pins, and 4 output pins, using the data direction register for port A, DDRA.  Zeroes are then sent out on all 4 output pins simultaneously, and, when a key is pressed, it connects one of those zeroes to one of the input pins, which the MCU then reads at port A and subsequently figures out in which row the key that was pressed is located.  The internal port A pull-ups are activated so that a floating pin will read in as a 1.

Here is the part of the code that's causing the problem:

 ldaa #%00001111  ;now find ROW
staa DDRA            ; 4 output pins, 4 input pins
bset PUCR,#$01   ;enable pull-ups on PORTA
ldaa #$F0            ;send 0s on column pins
staa PORTA
ldaa PORTA           ;check which row is 0

[software trap here]

The last line, reading Port A, is the problem.  When I hold down a key on the key pad, it does force one of the Port A pins low, as verified by the oscilloscope while the program is running, while the other 3 bits of the high nibble remain high, due the pull-ups.  I would expect, therefore, to find in the A register one of the bits--7, 6, 5, or 4--to be a 0, and the rest ones.  However, the A register always reads 0000xxxx.  I.e., all of the  high nibble bits are 0. 

So, when I read Port A, why do I not see the logic levels that I actually measure on the Port A pins? Adding to the conundrum, when I single step through the code using the DBUG-12 monitor, it works perfectly!

I am using the Dragon12-Light development board.

It is driving me crazy, so I will appreciate any help.  Thank you.

Labels (1)
0 Kudos
Reply
1 Solution
165 Views
Chandos
Contributor I

Thank you very much, Lama.  The problem was solved by inserting no fewer than 4 NOPs between write and read to port A, but I also had to add external 10-kOhm pull-ups on all 8 bits of port A.  When I saw that adding the 4 NOPs, alone, reduced the keypad read errors but did not completely eliminate them, and that single-stepping through the code gave no errors, I realized that there had to be a timing / noise problem.  In this case, it was ringing due to the ribbon cable connecting the keypad to port A (please see attached photo).  Unfortunately, the board designer did not terminate the lines between the keypad and port A, so that, when a low was sent from port A, bit 0, to port A, bit 7, for example, through the "C" key switch when pressed, that signal passed through the ribbon cable, whose inductance and capacitance produced significant ringing due to the high 24-MHz bus clock speed.  That ringing persisted longer than several NOP delay times before the signal stabilized at the low logic level, causing false reads.  So, in addition to the internal port A pull-ups, I added 8 external pull-up resistors, which finally fixed the problem.  The NOP delays, I think, could possibly be eliminated or reduced in number if I had carefully taken the time to measure the ringing and properly terminate the lines to eliminate it.  (The board designer apparently just copied the keypad circuitry from his earlier 68HC11 board where the clock frequency was only 2 MHz, and on which my program ran fine with no timing or noise issues).  Thank you again for pointing me in the right direction to finally solve a vexing problem (lab exercise for a college microcontroller class).

View solution in original post

0 Kudos
Reply
2 Replies
194 Views
lama
NXP TechSupport
NXP TechSupport

Hi,

Have you thought about speed of information in the internal circuits?

I suppose you should enter a small delay (nop or a few nops) between write and read port A.

 

Best regards,

Ladislav

0 Kudos
Reply
166 Views
Chandos
Contributor I

Thank you very much, Lama.  The problem was solved by inserting no fewer than 4 NOPs between write and read to port A, but I also had to add external 10-kOhm pull-ups on all 8 bits of port A.  When I saw that adding the 4 NOPs, alone, reduced the keypad read errors but did not completely eliminate them, and that single-stepping through the code gave no errors, I realized that there had to be a timing / noise problem.  In this case, it was ringing due to the ribbon cable connecting the keypad to port A (please see attached photo).  Unfortunately, the board designer did not terminate the lines between the keypad and port A, so that, when a low was sent from port A, bit 0, to port A, bit 7, for example, through the "C" key switch when pressed, that signal passed through the ribbon cable, whose inductance and capacitance produced significant ringing due to the high 24-MHz bus clock speed.  That ringing persisted longer than several NOP delay times before the signal stabilized at the low logic level, causing false reads.  So, in addition to the internal port A pull-ups, I added 8 external pull-up resistors, which finally fixed the problem.  The NOP delays, I think, could possibly be eliminated or reduced in number if I had carefully taken the time to measure the ringing and properly terminate the lines to eliminate it.  (The board designer apparently just copied the keypad circuitry from his earlier 68HC11 board where the clock frequency was only 2 MHz, and on which my program ran fine with no timing or noise issues).  Thank you again for pointing me in the right direction to finally solve a vexing problem (lab exercise for a college microcontroller class).

0 Kudos
Reply