Hi,
I am a new man in ARM CORTEX 4 and started with TWR-K60N512. However, after successfull in sample LED blink in IAR package, I try a new project that is mirrored from the sample project. But it got the failing when the IAR IDE could not load the runing file. Then I saw the RESET LED D2 is slightly bright. I tried to reset board but the problem still be fixed, RESET LED still was slightly bright. Then I measured the voltage @ reset_b of MCU and detected it is 1.5V.
I had tried to reset and turn off board, but all ways I did has no meaning. The board still not work.
Please to help me for this problem.
Thanks,
HUY
When I tried to load programe to chip via IAR IDE, an error diaglog box appear shows: "Could not write CPU register R15: written0x20000000, read 0xFFFFFFFE"
Does anyone ack to this problem? Please help.
Thanks,
Huy
I have the same problem.
Any ideas?
You can not access it, It might be secured already.
Try to unsecure it using Segger Jlink commander with "unlock kinetis" command.
If you have your flashed code enables Watchdog that resets the board continuously, or you have any other similar method that do that reset, the voltage measure on Reset pin will be at 1-2V because Reset pin is bidirectional pin that will drives LOW when reset situation occurred.
Regards
Dekiru
I am curious -- did you measure this 1.5V with a meter, or an o'scope? It may be oscillating! Can we also get the mask code from the top of your chip(s)?
ERGII
It is oscillating. You can view the pulse by oscilloscope.
If you use a multimeter, the value shown is "average" value...
Regards
I could use confirmation of the mask code, but if you see this oscillation AND you can't get control with JTAG tools it sounds like what we ran into with some Rev 1.1 chips in our circuits-- the POR circuits of Kinetis are supposed to start the chip at 1.71V, but we found we had to tie in an external reset controller to hold !RESET low until 'later' (in our case 10ms to get VDD to 3.3V) and this would allow reliable POR.
There may, of course, be other causes...
Earl Goodrich II
We have mask code 0M33Z and we cannot connect with it using JLink.
We thought it may be a problem with timing on Reset pin and tried to change value of capacitor and pull-up resistor at that pin but with no luck. Maybe the delay is still not long enough.
We replaced the chips with new ones. The new ones worked and that prototype is not inteded to go to mass production so we left the issue there with assumption we flashed wrong image into the chips
We faced another potential issue that sometimes the chip is locked if we push reset button. Do you see that also?
BTW, how to link between mask code and rev of the chip? I can not find that document on Freescale website...
Regards
So I take it this means you no longer have any examples of your oscillating resets -- too bad, I was hoping for more examples to provide to Freescale! Our 'reset trouble' with 1.0 silicon only surfaced at -30C. Altering the RC components on this pin do NOT seem to substantially alter the POR reaction. Our product doesn't have a 'reset button', so I have no experience there but having tied our POWERGOOD into the !RESET pin we haven't seen any issues with powerup startup. If you DO come across some new POR oscillations try holding your reset button during power-up and see if that comes up on release.
Mask Codes, as from errata documents:
0M33Z is 1.0 silicon (CPU ID reads '0'), which apparently had an 'excess delay' in the POR circuits and a 'non trivial' list of errata.
1N30D are 2N30D are the 'current' 1.2 silicon (CPU ID reads '2'), which have certainly corrected most of the errata (including that excess POR delay) BUT brought with them several functional changes as reflected in the current Rev 5 family reference manual, including the new flash swap mechanism and the deletion of the RTC_CCR 'Chip Control Register' (or more accurately change of same to RTC Interrupt Enable). I have not seen a concise list of such functional changes.
I don't recall the mask code(s) for 1.1, but they were a 'very limited run'.
--ERGII
Yes, all defective ones have gone... But we will make some similar boards in the future, I will try then let you know if we see it again.
You said they fixed it in rev 1.2 so it is not necessary to care about that issue anymore. The one we were using is engineering sample that is different from production qualified chip, so take it easy if there are some issues there.
BTW, Did you receive the information about that fixing via which channel?
Regards
We acquired 36 chips Kinetis K60 (PK60X256VLQ100 coded mask 0M33Z) on Digikey. Six of them were mounted on our boards but none worked. The pin 74 (/ RESET_b) is oscillating with or without any of reset capacitor. The activation of the reset switch has no effect, even during the power on. Somebody would know to tell if there is a problem with this version of the chip.
thanks
Regards
Caldas
Those Rev 0 chips certainly have a list of errata, and we had some POR issues 'cold' with that version, but found that if you held the reset button during power-on they would take-off on release.
I just designed a board with K40, and got 6 pieces at avnet.. unfortunatelly my board do not have a reset pin, and my chip got the 0M33Z mark so i belive it is a 1.0v.... any simple workaround here?
Thank you!
If you don't have access to the reset pin, all I can suggest is to try different Vdd risetimes, as that relates to internal POR sense and delays.
--ERGII
I see, just a question. Would work to reset the Kinetis after the power up.. or the reset pin should be low during power up?
I am having a problem flashing kinetis as described here: https://community.freescale.com/thread/97274
Would this reset problem be a possible cause?
Thank you!
The reset issues I've been working with all have to do with power-up, and holding #RESET active during power-up to control it. After power up the CPU would be 'lost' and further pin activations had no effect. This would be unrelated to any operations performed after the part was fully up and running.
I adquired 25 units of PK60N512VMD100 from ARROW (1N30D). I´m trying write internal flash memory with codewarrior 10.1 and P&E universal multilink, and i don´t get write the flash. Codewarrior says "write memory failed". The reset pin is oscillating also. Any suggestions?
I would check your hex code image to be sure that your reset vector contains the proper pc/sp, AND that the configuration values in the 0x400 space set the modes you need. An oscillating 'RESET_B' (averaging 1.5V) is usually caused by a very early 'core lockup' due to a bus fault from fatal flaws in the startup process (vector or early code). Failure to re-write device flash often means they have been secured. This MAY be recoverable with a multilink-type process similar to the J-link 'unlock kinetis', but not if the 'permament form' has been instigated. The chips may be 'toast'.