Important changes to forums and questions
All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.
9 years, 4 months ago.
K22F Board Locking up with load on output
When I add a high impedance load to my D4 PWM line on my K22F board it sometimes just locks up when I download the code. I can unplug it from the board and download it fine. I then reset the board and plug it in and it works just fine. The input impedance is like 10K, so I am certainly not overloading it.
This is rather odd but highly problematic behavior. I am just hoping someone else has seen this behavior and has a solution in hand. :)
BTW, I have the latest mbed bootloader as of just a couple of weeks ago.
Thanks!
1 Answer
9 years, 4 months ago.
D4 = PTA4 = non maskable interrupt. However mbed code is setup as soon as it enters the NMI to switch it to GPIO.
That said I quickly checked it, and it indeed seems to happen when I verify it. As soon as it starts, it starts fine even when I make D4 low. However when D4 is low when I reset the board it won't start at all. Not a clue why :(. Workaround at least is not having load to ground on that pin. If you use a setup with debugger you might be able to check out where it hangs exactly. I know this one was quite a pain to find the first time on Freescale boards, but the NMI handler was supposed to fix it:
void NMI_Handler(void)
{
gpio_t gpio;
gpio_init_in(&gpio, PTA4);
}
Btw since you seem to be using the K22F quite a bit, there is a known bug which can be really a pain if you get to larger programs: https://github.com/mbedmicro/mbed/issues/758
Btw2, LED_GREEN needs to be instantiated in the main function if you want to PWM it for example, that one is my fault :P. It disables that LED because by default it is on for some reason I forgot, but that might kinda overwrite the pin function if that is set by a global object:
void mbed_sdk_init()
{
pin_function(PTA2, 1); //By default the GREEN LED is enabled. This disables it
}
If you have a better solution I am all in favour of hearing it. :)
Ugh. So perhaps a weak pull up might avoid the issue on D4 until the GPIO overrides it? *sigh* :P
Regarding the nasty bug, so that is from CMSIS and beyond our immediate control, yes? Any chance that will be fixed soon, and if so, how do I pick up the fix from an already established project? I am dabbling in the mbed compiler for now as I become familiar with the platform but will need to move to native development via Kinetis Design Studio sooner or later.
I do plan on using the FRDM board as long as possible while our target is being done, so I will certainly plan on loading up the board. However, I don't know that I will hit the halfway point in the RAM anytime soon. However, we will be doing a lot of communications and touch UI stuff, and that is bound to start burning RAM.
As always, Mr. Erik, thanks for the help and all your good work. :)
posted by 18 Dec 2014Weak pull-up would work yes. But the current setup should also work, and it doesn't for some reason; the setting as gpio happens inside the interrupt handler.
It can be modified by anyone in the cmsis files. I might do it, when I can be bothered to do it :P. Since no one is paying me it is really matter of me being interested in doing it, but for now I only reported it :)
posted by 18 Dec 2014I thought I had posted this, but don't see it. Perhaps it "didn't take." I did add a 10K pull-up to Vcc on that line and all works perfectly. If anyone else sees this particular issue they can try that solution. I have not, yet, made an effort to optimize the pull-up value. I don't think of this as a problem in my case, but as I am using a Darlington pair driver for my output the 10K to Vcc is enough to turn it on until the micro powers up and forces the voltage at that node. That could be problematic in someone else's application.
posted by 23 Dec 2014
I tried looking into it further, but when it locks up on boot, even the programming interface doesn't boot up, and neither does the CMSIS-DAP debugger. So it might very well be also related to that. Although it also happens if I power it from the other USB port. Anyway without debugger and it just locking up there is little I can do to track this one down.
posted by Erik - 20 Dec 2014