Hi guys, The issue is after a software reset of the top hub, the following single line of code causes the micro to lock up: PORTA_PCR4 = (uint32_t)((PORTA_PCR4 & (uint32_t)~(uint32_t)( PORT_PCR_PS_MASK | P

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

Hi guys, The issue is after a software reset of the top hub, the following single line of code causes the micro to lock up: PORTA_PCR4 = (uint32_t)((PORTA_PCR4 & (uint32_t)~(uint32_t)( PORT_PCR_PS_MASK | P

Jump to solution
895 Views
john_fessler
Contributor II

Hi, I'm Braden, but my buddy Rick is having this problem with the MK10

Hi guys,

 

The issue is after a software reset of the top hub, the following single line of code causes the micro to lock up:

 

PORTA_PCR4 = (uint32_t)((PORTA_PCR4 & (uint32_t)~(uint32_t)(

                        PORT_PCR_PS_MASK |

                        PORT_PCR_PE_MASK |

                        PORT_PCR_MUX(0x06)

                      )) | (uint32_t)(

                        PORT_PCR_MUX(0x01)

                      ));

 

What this convoluted line of code does is turns off the pullup resistor on PORTA output 4.  The same command for PORTA output 5 works flawlessly.

 

Anything helps and thank you both.

 

Rick Henderson  | Senior Software Engineer

Labels (1)
0 Kudos
Reply
1 Solution
797 Views
john_fessler
Contributor II

Mark,

Thanks again, Rick was able to read back and found the NMI was in fact disabled.

The fact that you were looking at the same aspect was encouraging to him.

But that made him step back and look closer, and found a workaround.

Rick seems to think it is related to the fact that some of our sensors are up and running,

sending interrupts, during resets.

But he seems to have found a workaround that has tested overnight!

Best Regards,

-John

View solution in original post

0 Kudos
Reply
4 Replies
797 Views
mjbcswitzerland
Specialist V

Hi Rick

Probably the change is triggering a non-maskable interrupt on PTA4 (defaults to NMI) so either:
- change the pin first to NMI with pull-up (to avoid any glitches) and then to input as a second step
- or install first a dummy NMI handler so that it can handle the interrupt that fires
- or disable the NMI pin in the flash configuration

Regards

Mark

For less questions and faster, cheaper developments: try uTasker for Kinetis

0 Kudos
Reply
797 Views
john_fessler
Contributor II

Thanks Mark,

Rick says

"I’ve already used Processor Expert to disable the NMI."

Does this add a clue?

Best Regards,

Braden

0 Kudos
Reply
797 Views
mjbcswitzerland
Specialist V

Hi

Check the binary file that is loaded to the board and then the value that is read back from the flash configuration (in the area 0x400..0x40f) and verify that the NMI is really disabled:
1. I don't know whether PE always does it correctly or whether your configuration setup is maybe not at the correct location
2. Some debuggers change the value programmed to suit the one that they "expect" to be there (although I would expect this to be limited to the security setting and not others)

If you read back the value physically programmed and compare with the value in the flash configuration description you can quickly be sure whether NMI is disabled or not.

Regards

Mark

0 Kudos
Reply
798 Views
john_fessler
Contributor II

Mark,

Thanks again, Rick was able to read back and found the NMI was in fact disabled.

The fact that you were looking at the same aspect was encouraging to him.

But that made him step back and look closer, and found a workaround.

Rick seems to think it is related to the fact that some of our sensors are up and running,

sending interrupts, during resets.

But he seems to have found a workaround that has tested overnight!

Best Regards,

-John

0 Kudos
Reply