K40 PIT Isr issue when debuging

[pablintino]

Hi guys, im trying to create a simple blink project with CodeWarrior 10.6 and a K40 Tower System, but i have an issue with the PIT Isr.

I had read the Errata Sheet os the Kinetis MCU and i have fixed the problem that the Isr only works once, but now, another problem persists. The problem is that the ISR works (the ISR is triggered) only when I set a breakpoint in the Isr function (called pit_0_isr in my code), but the Isr is never triggered when no breakpoint is set.

I have tried a lot of configurations of the PIT registers (especially configurations related to the Freeze bit of the MCR register), and i'm suspicius that the debug mode is making strange things with the ISR behaviour.

I have attached the blink project and the main file to this post.

Has anyone an idea of what is going wrong?

Thanks in advance.

Original Attachment has been moved to: pit_project.zip

Original Attachment has been moved to: main.c.txt.zip

[mjbcswitzerland · Accepted solution]

Pablo

I just built your project with CW10.5 and had no problems - the LED always toggles with about 2.5us period - forever (irrespective of breakpoints etc.).

I recommend you build a FLASH target and flash it to your board to see whether it always behaves correctly (after power up and warm resets).

If this Flash version still causes problem, post a binary file (as created by CW10.6) so that it can be flashed to my board (it also has an old processor on it with the errate that can be successfully worked around !!). Ensure that the compiler version in CW10.6 is not optimising the workaround out of the code - CW10.5 compiler doesn't. [If thsi is happening and you have a PIT register view open it will be performing the workaround for you as it updates its view when stepping the IRQ code].

I have attached a binary file showing the TWR-K40 operating with PIT1 toggling the yellow LED every 500us - the red LED is toggled every 200ms by a SW timer so that you can verify that your board is OK (it does the workaround, otherwise the PIT wouldn't work correctly).

Regards

Mark

http://www.utasker.com/kinetis.html

P.S. In the code enabling NVIC interrupts I recommend using a define for the vector number rather than a fixed value.

enable_irq(68);

//Enable PIT IRQ in NVIC

This will make the code portable across all K and KL device's PIT use - the number changes with certain type of chip (also within a family) and fixed values will cause code to break unnecessarily in case you choose to move to another device or want to reuse the code for a different project (with different Kinetis).

[pablintino]

Thank you very much Mark!

I have been testing your solution and it works in my board. But when i tried to generate a binary output i realized that this option wasn't available!! Searching in this comunity i founded a post with an screenshot of the linker option when this option appears, and it was completely different, i was using the wrong compiler (GCC instead of Freescale Compiler). Now all is working, but i have one question, what's the difference between this compiler with Kinetis devices (i have used GCC with stm32 devices before)?

Thanks Mark.

[mjbcswitzerland]

Pablo

The GCC compiler is the preferred one for Kinetis devices and so I wouldn't use the old Metroworks/Freescale one (it doesn't support m0+ so can't be used with all Kinetis parts).

Every compiler and every version of a compiler (including GCC) is different but it should always produce working code (you need to contact GCC developers and invest many weeks of work to find out all details of its working and differences so it doesn't make much sense unless you want to be a compiler developer rather than an embedded programmer - I can^'t explain these because I know too little).

However, optimisation efficiency tends to increase with time and smaller/faster code can often be generated with newer versions. If one version/make doesn't work it can be due to a compiler bug but it is more likely due to non-portable code or code that the compiler's optimiser decides is not needed. Changing the compiler to solve a problem is - unless you can prove a bug in a certain version - not a good solution since such code will likely break again in the furure. I would have solved it correctly so that you know what the real problem was! Your code is very small so it woudn't take long to analyse the disassembler code to see whether the workaround access has been optimised away or not; simply ensuring that the compiler understands it as volatile may have solved it.

Regards

Mark

[pablintino]

I followed your advice and i created a new blank project with GCC. Surprisely it' works!, so i think i have touched something in the compiler options that makes that ISR issue.

Thank's for your advices Mark!