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

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

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

跳至解决方案
1,136 次查看
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

标签 (1)
0 项奖励
回复
1 解答
1,038 次查看
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 项奖励
回复
4 回复数
1,038 次查看
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 项奖励
回复
1,038 次查看
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 项奖励
回复
1,038 次查看
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 项奖励
回复
1,039 次查看
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 项奖励
回复