MKE02Z32 GPIO Problem

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

MKE02Z32 GPIO Problem

Jump to solution
1,573 Views
bernadettmarton
Contributor I

Hi Everybody,

I am working with MKE02Z32 MCU, and had a Problem discovered which I cannot explain.

I toggle one GPIO output (1st) in a 250ms Timerinterrupt and in my main Loop I set another GPIO output (2nd).

This 2nd disturbes the 1st GPIO signal. Instead of clear squer signal, I measure disturbances (see Picture).

I could reproduce this behaviour also in FRDM-KE02Z evaulation board with the demonstration SW package.

Have anyone meet with something similar? I would like to have an explanation for this phenomenon, and how to avoid it.

Thanks in advance!

0 Kudos
1 Solution
1,354 Views
mjbcswitzerland
Specialist V

Hi Bernadett

The registers that I listed allow RMW (Read-Modify-Write) to be achieved, which avoids risks of interrupts interrupting the modification process.

Now that I have seen the code it is clear that this is the problem. The example that you are using is a poor example since it doesn't respect one of the basic rules of embedded-system programming.

When using the original registers you need to disable and re-enable interrupts around the port change code to avoid the problem.

Regards

Mark

P.S. If you want a complete solution try the uTasker KE project (it also allows you to simulate your chip) since it doesn't do "examples" but instead is a proven entire solution for accelerated product developments.

View solution in original post

0 Kudos
7 Replies
1,354 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Bernadett Marton,

     We have reproduced your problem, and we are checking with Kinetis E family AE about this issue.

     I will let you know when there with any feedback, please wait patiently in the meanwhile.

     Thanks a lot for your understanding.

Kerry

0 Kudos
1,354 Views
mjbcswitzerland
Specialist V

Hi

How does the code write to the port(s)?


Do you use the GPIOx_PTOR, GPIOx_PCOR and / or GPIOx_PSOR registers, since these will not influence any other outputs.

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html
For simple, reliable, high-performance KE02: http://www.utasker.com/kinetis/FRDM-KE02Z.html / http://www.utasker.com/kinetis/FRDM-KE02Z40M.html

0 Kudos
1,354 Views
bernadettmarton
Contributor I

Hi Mark,

I used GPIOx_PDOR register as this is a R/W register. Is there any difference if I use  PDOR instead of PSOR and PCOR? As far as I correctly understood the user manuall there is no difference. If even though, where do I find a descriptions about this difference?

Thanks in advance!

0 Kudos
1,355 Views
mjbcswitzerland
Specialist V

Hi Bernadett

The registers that I listed allow RMW (Read-Modify-Write) to be achieved, which avoids risks of interrupts interrupting the modification process.

Now that I have seen the code it is clear that this is the problem. The example that you are using is a poor example since it doesn't respect one of the basic rules of embedded-system programming.

When using the original registers you need to disable and re-enable interrupts around the port change code to avoid the problem.

Regards

Mark

P.S. If you want a complete solution try the uTasker KE project (it also allows you to simulate your chip) since it doesn't do "examples" but instead is a proven entire solution for accelerated product developments.

0 Kudos
1,354 Views
bernadettmarton
Contributor I

Hi Mark,

Thank you very much, it explains the Problem I had. However the screeshot of the Oscilloscope is still strange.  After this explanation I would expect the Signal remains mostly on the low level with short high impulses.

With kind regards,

Bernadett

0 Kudos
1,354 Views
mjbcswitzerland
Specialist V

Bernadett

I can't comment on the exact waveform since I haven't seen the interrupt routine and also don't know what the PIT rate actually is in relation to the oscilloscope image.

In fact it may be that the PTC6 output actually toggle at twice the speed when corrected because some of the changes may not be taking place due to collisions between the main loop operation and the interrupt (sometimes generates a pulse, sometimes doesn't generate any visible change, sometimes change). The chance of disturbance looks to be very high since the main loop is doing virtually only the read-change-write back sequence - probably around 30% probability of error in each cycle.....

Regards

Mark

0 Kudos
1,354 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Bernadett Marton,

     Mark is correct, we suggest you use the GPIOx_PSOR, GPIOx_PCOR, GPIO_PTOR.

     Because these register is write only register.

     GPIOx_PDOR is the write and read register:

pastedImage_1.png

    And PTOR also can change this register, this is why your attached wave happens.

   In your while(1)

{

        GPIOA_PDOR |= 0x00002000;

}

        GPIOA_PDOR |= 0x00002000;, this code should be divided to 3 steps:

1. Read PDOR register

2. Change the data

3. write the changed data back to PDOR register.

If you in the Step 2, the PIT interrupt happens, then the PDOR already be changed to another data.Take an example, when While read PDOR data, the PTC6 is 1, then interrupt happens, the PTC6 bit has been toggled, it is 0, but in while (1), code GPIOA_PDOR |= 0x00002000;, step 2 still recognized it as 1, when go to step3, the PTC6 will be write to 1.

  This will make your problem.

  In conclusion, your problem is caused by the PDOR can be read and write, we suggest you use GPIOx_PSOR, GPIOx_PCOR, GPIO_PTOR.

Wish it helps you!

If you still have question, please let me know!


Have a great day,

Kerry

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos