MK64 startup problem - IRQ exceptions, won't run to main

[nickwallis]

Hello All,

I am struggling to get a new board up and running with KDS 2.0 / KSDK 1.1.0 / Bare metal / Non-processor-expert / custom hardware (MK64FN1M0VMD12)

I have built some basic code, based on the examples in KSDK

All of that seems OK - I have built the platform library, and the code compiles OK.

But, when I debug the code, it is not running to main()

I am getting exceptions and the code runs to the default ISR handlers in startup_MK64F12.s

I have tried adding my own ISR handler functions in main.c, but as one problem is fixed then another one appears - e.g. I added a handler for the EWM interrupt, but then it's stuck at the handler for, e.g., the USB. etc.... etc.....

I have tried globally disabling interrupts using INT_SYS_DisableIRQGlobal() but this made no difference.

Help!

My questions:

1. Are interrupts enabled/disabled on startup by default?

2. If they are enabled, how do I disable them? INT_SYS_DisableIRQGlobal() did not seem to work.

3. Do I need to install my own ISR handlers to overwrite the default ones?

4. Any other pointers as to what might be stopping my application running to main()?

thanks!

Nick

[ahmedwahdan]

any updates?

I use segger J-link with MKL34z64, code works ok on debugging but no interrupts are vectored and nothing at all works without debugger.

[nickwallis]

An update on this.

I have just downloaded KDS 3.0 and KSDK 1.2.

Imported projects "hello_world_twrK64f120m" and the platform lib into the workspace.

Built all and started a debug session.

On my own custom board, the code runs to main() each time and I can step the code. My custom board is the same as before.

So, I am still not sure what the problem was before, but using the latest versions of the tools appears at this point to have resolved the issue. (still early days I know)

I will continue working with the new tools versions and report back later.

thanks

Nick

[mjbcswitzerland]

Nick

The values 0x13 and 0x18 are not directly the values used by the input divide/multiplier - you need to see the table in the user's manual.

These values mean (assuming 50MHz oscillator input) 50MHz / 48 (= 2.5MHz) * 48 = 120MHz

If you have 25MHz instead of 50MHz simply change the input divider to be half the vaue (this is to /10, which is 0x09 instead of 0x13).

In the case that we investigated, the processor was still operating from its default state (see µTasker MCG Configuration Support ) whch is in FLL mode from the internal slow clock, at a system clock speed of around 20.97MHz. The fact that you have a different clock input will only be noticed when you try to lock the PLL since it will probably not achieve lock due to the fact that its input frequency is a litte to low (2.0..4.0MHz range expected).

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nickwallis]

I wonder if this could be because of incorrect clock settings in system_MK64F12.c/.h?

I just discovered that my processor is running off a 25 MHz clock instead of the expected 50 MHz ;-)

I am currently trying to understand the PLL configuration settings in the above files, to change them to a 25 MHz input clock

But the settings for PRDIV0 and VDIV0 for predefined clock mode #4 don't make much sense so far, as they result in a fractional divide.

i.e. for CLOCK_SETUP == 4, the value for PRDIV0 is 0x13 and for VDIV0 is 0x18

So the expected clock is (25 MHz / 0x13) x 0x18, which is not an integer.

Nick

[giacomopetrini]

I think you need to add the xxx_irq.c files to your project, else the interrupt vector doeas not know where to go when an interrupt is triggered.

Best Regards

Giacomo

[mjbcswitzerland]

Hi

The interrupts are still disabled when this happens - and the IRQs all exist in the vector table.

The same code runs with KDS and the OpenSDA debugger on a standard board.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nickwallis]

Hi Mark

The disable watchdog didn't seem to make any difference.

I am sure this is something really simple, but it is taking time to find it for someone new to KDS/KSDK like me!

Can I take you up on your very kind offer of 1 hour of free debugging please?

thanks

Nick

[mjbcswitzerland]

Hi Nick

I believe that you are located in Sheffield, UK, so it is probably too late today (Wednesday) but just send me an email (or a private mail via the forum) and we can get it sorted tomorrow if you are available.

Send me your Skype name or a fixed line telephone number (Skype tends to be easier rather than holding a phone while working but a fixed number of fine if you don't have an address and/or headset) with a time that best suits you (best early afternoon for me). So that I can directly control KDS, make sure that you have Chrome installed on the PC as well as its free remote desktop extension.

If you have a standard Freescale HW (like the FRDM-K64F or TWR-K64F120M) it would be best, to exclude anything that may be hardware related, but we can also directly work with a custom board if that is not possible.

I'll then talk you through the initialisation and hopefully be able to detect what is going wrong and put it right so that you can move on to the next development steps.

Look forward to a debugging session shortly.

Regards

Mark   [mark (at) uTasker.com]

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nickwallis]

Latest update on this :

I have tried for several days to get this working on my own hardware, with no success.

Had a very useful debug session with Mark which pointed to possible debugger or toolchain issues - the processor would step some instructions, but not others.

Next, I downloaded IAR Embedded Workbench for ARM and requested a Kickstart license. Within about 1 hour I had my own board up and running simple demo code which flashed an LED.

I will do some more digging to try and find out why this is not working using KDS2.0 / KSDK1.1.0 but works fine using IAR. Buggy startup code perhaps? Has anyone else using K64 had issues?

regards

Nick

[Jorge_Gonzalez]

Hello Nick Wallis:

Are you having the same issue?

So far I have not seen any problems with the default KDS/KSDK startup code for K64.

Here some pointers and questions also:

- In your custom board pay attention to NMI pin (PTA4). It should not be somehow grounded, otherwise the NMI interrupt will trigger and if you do not have the corresponding IRQ handler then the execution will hang.

- Did you try the same project with an evaluation board (e.g. FRDM-K64F)? Did it work?

- There is a getting started guide with K64, KDS and KSDK:

https://community.freescale.com/docs/DOC-103288

If you wish please attach your project so I can give it a check from my side.

Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[nickwallis]

Hello Jorge,

Thank you for your reply.

Yes, I still have the same problem. I have checked with an oscilloscope and the NMI pin is definitely high - this pin has a local 10Kohm pullup resistor to the processors VDD supply (+3.3V)

The problem I have remains, the code does not run to main() on my custom board when I start the debugger. It normally ends up in some exception handler, not always the same. And when I try and step the code from there, it is not always able to execute the instructions (e.g. see the attached screenshot).

I am using the example code for hello_world_twrk64f120m, the same code works OK on my TWR-64 board - it runs to main.

I have tried my custom board using an example project from IAR EW for ARM, and that works fine - so I think the custom board is OK.

Archive project attached. Any ideas?

regards

Nick

[mjbcswitzerland]

Jorge

I can confirm that Nick's problem is of the following nature:

1 - the processor will reset and take its reset vector normally

2 - all memory accesses are OK (flash content is correct and can be correctly read and dispayed by the debugger, and the stack is set up correctly and all RAM locations can be correctly written and read)

3 - The first instruction is cpsid i.
If an attempt is made to step this instruction with the SEGGER J-Link debugger connected to KDS it doesn't result in any stepping activity - it stays at this line (with no indication of errors or why)
4. If the PC is moved to the next instruction ldr r0, =_NVIC_ICER0 stepping works normally for a few instruction until certain other instructions are encountered, such a str r2, [r0], #4 and then the debugger will not step this line and just stay there.

I have never encountered such behaviour before but the combination of the Segger J-Link and IAR embedded workbench operates normally with the same board.

My tentative conclusion is that the problem is restricted to the KDS / J-Link combination, as if the processor is set to a mode that can't handle certain instructions in.

Nick was going to try using a different debugger type with KDS to see whether there is a difference so that KDS could be used.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nickwallis]

A quick update on this, I think I might have found a problem.

The code which disables the watchdog is there (its in the function SystemInit() in startup_MK64F12.c), but it's inside a #define which I cannot find a reference to anywhere else. So I don't think this code is getting executed, therefore the watchdog is not disabled.

I am using standard unmodified KSDK startup code (and drivers) - no changes or deletions from me.

I will #define that macro for the watchdog and see if it helps!

thanks

Nick

[mjbcswitzerland]

Nick

- Interrupts are disabled by default (apart from NMI) - NMI pin can be disabled in the flash configuration area.

- The watchdog must be configured as first thing after a reset (within about 250 clock cycles) otherwise you will get a reset. - see page 33 of http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis_demo.pdf

- It is not possible to step through watchdog initialisation code with the debugger (it will always cause the watchdog to fire)

- Other than that accesses to non-existent memory will always result in a hard error.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nickwallis]

Hi Mark

Thanks for the reply.

Do you know if the startup code takes care of the watchdog after a reset? Or do I have to do that as the 1st thing in main()?

Anyway, I tried disabling it in main using the following KSDK macros:

BW_WDOG_STCTRLH_DBGEN(WDOG_BASE, 0); // - 0 - WDOG is disabled in CPU Debug mode.

BW_WDOG_STCTRLH_STOPEN(WDOG_BASE, 0); // - 0 - WDOG is disabled in CPU Stop mode.

BW_WDOG_STCTRLH_WAITEN(WDOG_BASE, 0); // - 0 - WDOG is disabled in CPU Wait mode.

I am not sure if this meets the 250 clocks requirement or not - I will have to dig depper into the startup code to find out.

When I enter debug, the same problem is happening as before. The debugger gets stuck at DefaultISR in startup_MK64F12.S, WDOG_EWM_IRQHandler()

I have a scope probe on the microcontrollers reset pin, and as expected it is high apart from when the board powers up, or when the J-Link resets the target.

Nick

[mjbcswitzerland]

Nick

Watchdog disabling will be about the first thing done in all available source code so it is probably there unless you removed it.

It looks something like

UNLOCK_WDOG(); // open a window to write to watchdog
WDOG_STCTRLH = (WDOG_STCTRLH_STNDBYEN | WDOG_STCTRLH_WAITEN | WDOG_STCTRLH_STOPEN | WDOG_STCTRLH_ALLOWUPDATE | WDOG_STCTRLH_CLKSRC); // disable watchdog

The code that you have added is just controlling some of the flags and these will only be reacted to when the watchdog has been unlocked and the write is performed within the window that was opened by the unlock sequence.

There is a not a lot that can go wrong with the initialisation apart from the watchdog, setting the stack pointer incorrectly, setting clocks incorrectly (out of spec) or hardware problems like missing power supply lines so that the flash is unreliable (possibly only at higher speeds). Plus of course incorrect source code or settings. About the last thing that I have experienced in this area is that the JTAG or SWD lines, that are multiplexed with ports, are reconfigured as ports duing initialisation and the debugger connection breaks down - but I don't think that this is your case.

You don't need to worry about the port muxing in general since all pins defaut to certain functions and there is no reason why defaults should cause problems.

The usual method is to take a standard project for a development board close to your own board and step the initialisation (without trying to step the watchdog part, which will otherwise always fail). Then do the same on your new board - if you set up with standard project for internal clock sources it doesn't matter about external clock differences etc. either.
If the standard board works but your HW doesn't you need to go through the checklist of possible causes until you find the reason.

In case you do need help, I have a (almost) complete set of Freescale Kinetis Tower and Freedom boards and reference projects that can be loaded which will allow verification of startup and/or almost all peripheral functions. I can control your IDE over remote desk top and identify what your problem is quite quickly. I'll offer you 1 hour free remote desktop/Skype support (you will need Skype and Chome with its remote desktop extension installed) if you like (this is what I do professionally and have developed several K64 products in the last year and solved various starting difficultes for clients) and expect that this would be long enough to get you past the difficulty (as long as it doesn't need HW changes).

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support / µTasker Kinetis TWR-K64F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[nickwallis]

Hi Mark

Thanks for the pointers and the kind offer.

I will try some of the suggestions and let you know how it goes.

cheers

Nick

[egoodii]

Put in a hard-fault handler that allows you to see the diagnostic info saved therewith.  I have posted one.

[adriancano]

Hi,

Are you using a custom board or one of the FRDM or TWR boards for the K64 device?

Regards,

Adrian

[nickwallis]

Hi Adrian,

Thank you for the quick reply!

This is our own custom board - a new board, only turned on this week.

Although I do have a TWR64 and a FRDM64, so I guess I could try the code on that. I haven't done this yet. There might be some pin muxing differences to take care of though.

This raises another question - as this is a custom board, presumably I should setup all of the pin muxing for every pin on the device, even if to begin with I just want to start with some simple basic code? (because if I don't, then there might be pin conflicts and contention, maybe even some damage?) If so, what is the recommended method for setting up the pin muxing? I didn't really get as far as setting that up yet - because my code is not getting to main()

thanks

Nick