[ARM] Interesting reset pin activity on Freescale Kinetis KL26 microcontroller

Status
Not open for further replies.

Los Frijoles

Full Member level 1
Joined
Oct 5, 2006
Messages
98
Helped
9
Reputation
18
Reaction score
5
Trophy points
1,288
Location
Provo, Utah, United States
Visit site
Activity points
2,252
I just assembled a board that I have created that basically acts as a breakout board for a MKL26Z32VFM4. Today, I am trying to get it to communicate over SWD so I can program the initial bootloader. I've never done anything like this before and this is basically an experiment for myself to see what it takes to go from datasheet to working device with one of these microcontrollers.

I have another microcontroller emulating the SWD interface and it might not be emulating it properly (I haven't yet actually counted the pulses to make sure it is using 50 pulses to initialize). In any case, the KL26 failed to respond when I held RESET_b low.

I decided to see if the processor was even starting, so I put the oscilloscope on the RESET_b pin when it was left floating to see what would happen. According to the datasheet, it is pulled up internally and during the boot sequence it is driven low until the processor reaches a certain state. It then releases the pin and sees if it is rising fast enough (KL26 family reference, 6.3.3). If it isn't it keeps the processor in reset mode.

I see the following waveform on the RESET_b pin (pin PTA20):



This doesn't look right at all. I should see it just simply high, not making a nice RC curve between 0 and 3V at approximately 30kHz (it's really wiggly as can be seen).

My theory: It is somehow stuck in a boot loop since it is driven low quite rapidly.

I could put a resistor on the reset to raise it to 3.3V, but I'm curious as to why this is happening. There are possibly a few mitigating factors:

* This is my very first QFN chip that I have soldered by hand. I soldered it by tinning every pad, laying down flux, setting the chip on top, and then heating up a via-connected thermal pad on the back of the board for approximately 5 seconds while tapping the chip with tweezers. It appears to have soldered well and the 3.3V usb regulator seems to be working fine (at least the voltmeter and oscilloscope say so). It is possible that I have a void somewhere or a cold joint.

* There was an ESD incident when the device was powered off and not connected to anything. I touched it with both hands to lift the board from my breadboard and felt a slight shock. The regulator still works and the chip doesn't let out smoke or heat up when powered on, so I'm not sure what happened here and if it is a problem. I have 2 additional backups that I could use, but that would require assembling them. I swear, if this is the problem I'm going to buy an ESD strap right away (yes I'm assembling this in my apartment, on a computer desk, sitting on a carpet, and it's cold outside (i.e. low humidity inside)).

In any case, my questions are:

* How do I properly connect the chip for SWD? It's powered on, reset held low, and SWD connected to the appropriate pins, right? Am I missing something? My SWD program outputs 50 clock cycles, issues the SWD switchover command, outputs another 50 clock cycles, and attempts to read the IDCODE register.

* What could be causing this strange RESET_b behavior? Did I break something and have to start over?
 

I just assembled a board that I have created that basically acts as a breakout board for a MKL26Z32VFM4.
* What could be causing this strange RESET_b behavior? Did I break something and have to start over?
Hello, I just assemled a board with MKL26Z64, 64-pin TQFP package. I get the same result as you (pulses are at 27kHz). When I try to pull /RESET pin at VDD level via the ampermeter, I get 14mA current flowing (e.t. it refuses to go high and de-assert reset).
I begun to think that I damaged the device. The internal USB regulator is working OK, used only as ADC ref. I power the core directly. The consumption of the whole device is ~ 4.4ma (I have a power LED via 1K resistor).
Somebody at different forum said, that the reset behavior is normal for an un-programmed chip. It is crashing (main() returns) and being reset by the watchdog timer.
So maybe it's waiting proper SWD initialization......
 

Hello, I more or less solved the problem with my custom KL26 board.
I used OpenOCD with a modded FRDM-KL25Z board (to become CMSIS-DAP compliant SWD adaptor) to program the chip as if it were from KL25 series.
To program it, i needed to halt the chip ( OpenOCD couldn`t). So I FORCED the pin to GND & ran the OpenOCD, then entered "reset halt" in the command terminal, the "flash probe 0" command worked & detected Kinetis flash, so I released the reset pin and tried to write 64k from the image I took from the KL25 chip (I had no binary for KL26). It reportedly went OK. After that I don't need to force the reset pin low anymore - now the OpenOCD is able to halt it and step the code. I can`t see signals on the pins, but it`s normal since i took compiled code for 80-pin KL25 chip and shoved it into the 64-pin KL26.
I soldered also a 100nF capacitor between "/reset" pin and GND and 10k pullup to VDD (later it turned out it has an internal pullup). Loosely lost 3 days to figure it out 'Would be glad If I helped someone.
 

Status
Not open for further replies.

Similar threads

Cookies are required to use this site. You must accept them to continue using the site. Learn more…