10 years, 4 months ago.

*Urgent & Serious* KL25Z does not boot when using both falling and rising interrupt.

Hello All,

Please see this program:

Import programKL25Z_not_booting

Code for bug report; KL25Z not running when PTA4 hasn't been high for > 400ms

When I reset the mbed with pin PTA4 low, it won't continue to the main routine. Only after +/-400ms 'high' level on PTA4 it will continue; it works fine after that, but this is a very large bug as I'm trying to teach a class how to use encoders ... Now the program will start, depending on the motor position. If the position is "wrong" (level on PTA4 is low) we have to slooowly turn the motor to get the program going...

Even worse...

I now found out that when using PTD4, the program stops executing anywhere in the program. This looks like some kind of race condition! The program runs as expected when removing either the falling or the rising interrupt.

Can this please be fixed, or can someone help me to find a workaround?

#include "mbed.h"

DigitalOut rled(LED_RED);
DigitalOut bled(LED_BLUE);
DigitalOut gled(LED_GREEN);
InterruptIn test(PTA4);

void falling()
        bled =0;
        bled = 1;

void rising()
        gled =0;
        gled = 1;

int main()
    while(1) {
        rled = 1;
        rled = 0;

2 Answers

10 years, 4 months ago.


@first issue please read this link http://mbed.org/questions/1387/How-can-I-access-the-FTFA_FOPT-register-/, same problem as you are facing, I was able to reproduce the problem with NMI if you set PTA4 low. There's also solution proposed, let us know if that works for you.

@second issue How to reproduce this? If I change test pin to PTD4, the program works. Please comment with more details.


Accepted Answer

@first: I'm going to take a look at that! @second, that is other than I thought; I still had PTA4 connected, did not reckon it would influence my PTD4 InterruptIn, but it did.

posted by First Last 15 Oct 2013

I tried the suggestions from the first link, both trying to change line 202 in startup_MKL25Z4.s to

FOPT            EQU     0xFF

And adding

void NMI_Handler() {
    DigitalIn bla(PTA4);

in all possible combinations and nothing changed. I'm now going to tell everyone to leave PTA4 open, but I think this really well.... screws up the "easy implementations" on the mbed. <grumpy>On a side note: the same students with this problem also used PTA1 and PTA2 for other interrupts, which get overwritten by stdio communication when using USB serial.... Also badly documented.</grumpy>

posted by First Last 15 Oct 2013

That PTA1 and PTA2 are used by stdio is shown in the pinout. Could be clearer, but it is there.

Regarding NMI_Handler, don't forget you need to add the extern "C" part in front of it. (In my code where I tested it there I had extern "C" void NMI_Handler; defined above my code, then that isn't required. I think you may define it anywhere in your code, but not 100% sure). If you don't do that it just sees it as yet another function you can call. With it it puts it in the interrupt handler.

Personally I do agree it makes more if the mbed compiler script gets sets to disable that interrupt by default. Users can always enable it again, but for the default user it is better to have it disabled. Luckily Martin remembered/knew the cause of this one, I completely forgot about it.

posted by Erik - 15 Oct 2013

Hello Erik, Thanks for your comment, I was in a too fast and furious attitude yesterday :) Now added the "extern c", and that works. the repository is updated now!

The other fix, in startup_MKL25Z4.s also works, I changed the wrong version, you need to change the file in mbed-src/targets/cmsis/TARGET_Freescale/TARGET_KL25Z/TOOLCHAIN_ARM_STD/

posted by First Last 16 Oct 2013
First Last
10 years, 4 months ago.

In the repository I linked to in the first posts, two fixes are implemented in different revisions

  • Fix by adding a new NMI handler
  • Fix by changing startup file

If any of these could be reverted back into the mbed repository that would help a lot....