Hi, I'm new to the KDS environment, I can not make it run smoothly.

[ludekdrobny]

Hi, I used to use CW10.6 within Eclipse plus Processor Expert components and MQX-Lite RTOS.

Now with our new hardware design featuring Kinetis MK10FN1M0VLQ12 MCU I am trying to switch to KDS 3.2.0, using PEx components and also Erich Styger's component for FreeRTOS 9.0.0.

I came across several topics I have problems to solve:

- "my" MCU is listed in KDS 3.2.0 list of supported devices. But very often it seems KSDK kit should also be installed (v.1.3 or v2.0). But neither v.1.3 nor v2.0 supports "my" MCU. The best fit seems to be MK10DN512 supported by KSDK v1.3, but it is not the same chip. When I install Erich Styger's PEx component for FreeRTOS 9.0.0 it also installs some referenced componnets that ask me what type od KSDK   am I using, option "none" is not available. On the other hand I saw a post here featuring "my" MCU and it uses KSDK v1.3. What is the best configuration for my project?

- With the KDS I am using a P&E micro Multilink FX debug probe. I can very ofter make it running after a restart of the complete KDS and almost never when trying to relaunch the same project later. Restarting the KDS generally helps. Looks like my Debug session is not properly set-up, yet I believe I played with the setup long enough.

- sometimes I get a strange console message:

It looks like a message from the debugger server (GDB) that tells me to go to the menu options. I simply didn't find it.

- My first task of my project is to make sure the free running FreRTOS on my complete PCboard consumes the minimal possible current. During the hw initialization I set many pins to their proper values so that my modules on my board are switched off. After the switching-off of the modules I am stopping the MCU completely to make sure it draws the minimal possible current (using PEx Cpu_SetOperationMode(DOM_STOP,...)). The next Debug session is unable to get the MCU out of this state (I am using P&E Multilink FX with the 20-pin connection). What always helps is to press my manual reset button on the board. The JTAG TRST signal on my probe is connected. The MCU PEx configuration has the nTRST checkbox in the JTAG interface checked. It looks like the debugger is unable to get the MCU from the STOP mode.

- there are some more issues but not so urgent and severe as these. Could someone please give me some advice?

[ludekdrobny]

Hi Erich,

I made some progress by installing the P&EMicro update. Still, the strange "C file" with a name of 0xa5c keeps opening during every debug session.

Reset signal: I use Microchip MCP130T-300 reset/ generator with an optional pushbutton for my debugging. Very short trace etc. The problem migth be that the reference manual says the reset pin has its internal pull-up and the MCP130 also has a 4k7 pull up. I can replace it with a MCP120T-300 which is the same circuit minus the pull-up. But no other loads are present there, definitely no added capacity.

I will try the updated version of P&EMicro and see the results.

Shell and Wait don't work: Shell requires to choose a KSDK version, I have none. So far I haven't seen any characters coming out of the serial channel I specified for the shell. Didn't have much time to look at it more closely. Wait component seems to generate no delay at all. I believe there is some bug on my side. Also I do net see any FreeRTOS task awarness of the GDB.

For me the most important task at this moment is to build an "empty" project with FreeRTOS taks runnig and Idle task sleeping most of the time to see a low power consumption. So soon I would be looking for the RTOS task trace features to see what is going on on my board.

I will come back with more accurate info later.

Thanks

Ludek

[BlackNight]

Hi Ludek,

the internal pull-up is a 'weak' one, I always have used an external reset line pull-up, especially to avoid noise coming into the reset line.

As for the KSDK component: you should specify 'none' as SDK if you are not using any.

FreeRTOS awareness you don't get out of the box with GDB. You need to use e.g. the Segger GDB server (see https://mcuoneclipse.com/2016/06/13/adding-freertos-thread-awareness-to-gdb-and-eclipse/ ).

Erich

[ludekdrobny]

Hi Erich,

with the reset signal it should be ok as my MCP130 reset generator has its own 4k7 pull-up installed. No capacitors.

Regarding the RTOS awarness with GDB: I am using PEMicro Multilink FX, PEMicro also has its GDB server quote: " NXP's Kinetis Design Studio already has the plugin seamlessly built into the product.". But they don't mention any RTOS awareness. I believe that going to Segger GDB Server I would need one Segger J-Link probe too.

[BlackNight]

Hi Ludek,

yes, this is server dependent, so that implementation is for Segger, so you need a J-Link probe for that. I had contacted P&E a while back if they could do the same in their GDB server, but have not seen it implemented yet. It might help if you ping them about this feature too ;-).

Erich

[ludekdrobny]

Hi Erich,

this is exactly what I did earlier today. I posted a question at P&E micro. By the way, to avoid these problems I bought the full IAR WorkBench plus their I-jet Trace debugging probe for this purpose two months ago. Now it rests nicely in my shelf as I am busy with making my custom board running FreeRTOS 9 under KDS + GCC. I have the P&E micro Multilink FX available from my previous (non-Kinetis) projects.

[BlackNight]

Hi Ludek,

- SDK or not: that depends on your needs and your application. But newer devices are supported by the SDK, so this is likely the way going forward. And additional devices get added to kex.nxp.com. I quickly checked it today, and indeed the k10fn1m is not supported there yet.

- debugger cannot connect: check if you have another pegdbserver running (see https://mcuoneclipse.com/2015/05/18/gdb-client-and-server-unlocking-gdb/  and https://mcuoneclipse.com/2014/11/03/debugging-failure-check-list-and-hints/ ). Most of the time it is a stuck GDB server which can be killed from the task manager so you don't need to restart KDS.

- The 'no reset script file' message is a bogus message and can be ignored. This should be fixed in the latest P&E version. Check with the menu Help > Install New Software and using the P&E update site (http://www.pemicro.com/eclipse/updates ).

- STOP mode: several low power modes, including STOP are turning off the debug circuit on the device, so for the debugger it is like power is lost. You will not be able to debug through such a low power mode. This is h ow the hardware is designed.

I hope this helps,

Erich

[ludekdrobny]

Hi Erich,

thanks for your comments. MK10FN1M0VLQ12 was my choice some time ago, the custom board has been designed and built, currently I am holding the pilot series of 10 pieces. To make the board alive I had to choose the environment. Because of PEx th KDS seems to be the only solution available. Do you think NXP will add this MCU into say KSDK v1.3 because the MK10DN512 is already supported there? Where can I get relevant information how/when the MK10FN1M0 will be supported? As I mentioned in my first post I have downloaded your PEx component for FreeRTOS (approx. 14 days ago), I can launch tasks there, so basically it works but I cannot make the referenced components running (Shell, Wait, KSDK). So the FreeRTOS is not working properly for me (yet, I hope).

I have read most of the articles/posts on your mcuoneclipse.com, so I am aware of most of the advices reagrding GDB. I believe I have configured the GDB with some mistakes, it behaves erratically. Right now the debugging session opens a previously unknown message with some nonexistent .c source file 0xa5c, see below.

Right now I am trying to upload the latest PEMicro Software, it is calculating requirement for the last 15 minutes. Doesn't work, I will give it another try tomorrow.

Thanks for the explanation of the STOP mode. I am not going to use it in the real project, this is for me just the quickest way to cut off the power consumption of the MCU as I am lookinng for other sources of unwanted current consumption. But it is good to know why the debugger probě was unable to leave the STOP mode.

[BlackNight]

As for SDK roadmap, it is here: Introducing Kinetis SDK v2

I don't think there will be further SDK 1.x releases.

Erich

[BlackNight]

Hi Ludek,

the problems with debugging your hardware could be related to the boards. For Kinetis the circuit around the reset line (capacitor, pull-up resistor) can be critical. I had on one of my boards a C too big, and this cause issues as the debug interface was not able to pull the reset line down fast enough.

I don't see why Shell or Wait should not work. If you can post your project, I can have a look.

Erich