FRDM-KL03Z debug, LED and SPI

[enrico]

Hi all,

I am moving my fist steps with uTasker and I need some guidance to understand how things work.

1) I've followed this guide to run uTasker and create the first task
http://www.utasker.com/docs/uTasker/uTaskerV1.4_user_guide.PDF

However, I can't see the output of fnDebugMsg. I am using OpenSDA to debug (PEmicro drivers, KDS 3.0), and I am expecting the output on the terminal (I am using Tera Term). Am I missing something?

2) As a first example I want to trigger some LEDs on and off. Is there any basic guide on how to create this simple task?

3) I need to setup an SPI connection, and in the past I was using PEx for that. What is the best way to do it without PEx? It seems like the nRF24201 module is a good starting point, but I wonder if there is something more specific.


Thanks,
Enrico

[mark]

Hi Enrico

1. I recommend that you load the binary file from http://www.utasker.com/kinetis/FRDM-KL03Z.html to verify that your board and the OpenSDA communication link is working.

If you build the project for your board it should use the correct UART debug interface by default.

2. The project will alway flash an LED at 2.5Hz when operating normally. This is controlled by the watchdog task.
In the debug command line menu there is an I/O sub-menu with commands to configure some ports as inputs and outputs, and change their output states. You can use these as reference.

3. There are various SPI examples in the code. As well as the nRF24201 interface there are SPi Flash drivers (spi_flash_kinetis_atmel.h, spi_flash_kinetis_s25fl1-k.h, spi_flash_kinetis_sst25.h, spi_flash_kinetis_stmicro.h and spi_flash_w25q.h). In these you can see the interface to the SPI, which is based on macros such as WRITE_SPI_CMD0().
Furthermore, the SD card SPI interface is also a useful reference; see INITIALISE_SPI_SD_INTERFACE() in app_hw_kinetis.h for configurations.

Regards

Mark

[enrico]

Hi Mark,

Thanks for your answers.

1. I tried to load uTaskerV1.4.8_FRDM_KL03Z_RF.bin and I was getting on tera term the prints "Ping RF". However, I still can get the prints in my project.  Once I build the project I run the debug with PEmicro interface, power off and on and the green LED starts blinking. Not printing on tera terms tho. Any idea?

I've also tried to just uncomment #define nRF24L01_INTERFACE and see if that would get me to "Ping RF", but in that case also the green LED blinking stopped working.

EDIT:
Apparently it was a clock problem. I switched from LPUART_IRC48M to LPUART_MCGIRCLK in app_hw_kinetis and now the UART is working and I can print on terminal.
 

2. Where do I find the "debug command line menu" on KDS?

3. Great! I will look into those files.


Thank you!

[mark]

Hi

The command line menu is on the UART. It is printed out when the ENTER key is pressed (as long as USE_MAINTENANCE is enabled when buildig the project).
The I/O menu is menu 3 "Go to I/O menu".

Regards

Mark

[enrico]

Hi Mark,

I'm still having problems with the LPUART to print on console.

My code is something like:
  fnDebugMsg("Send Data\r\n");
  fnDebugMsg("Rx Data\r\n");
  fnDebugMsg("Receive Data\r\n");
  fnDebugMsg("data1=\r\n");
  unsigned long  ucTestData_rx2=66;     
  fnDebugHex(ucTestData_rx2,sizeof(ucTestData_rx2)| WITH_LEADIN);

But this is what I get.                                                                    

Hello,`world...`KINETIS
Send`Data
Rø`Data
Receive`Data
data1=
pøpppppp42


I assume is some problem with the LPUART setting. As in my previous post, I'm using LPUART_MCGIRCLK instead of LPUART_IRC48M. With LPUART_IRC48M I can't see anything out in the console. I wonder if this is related to the problem.

Any idea?

Thank you,
Enrico

[mark]

Hello Enrico

Are the ` and ø` in the output errors? If so, have you measured the speed of the LPUART's output to be sure that it is accurate and not slighty off (and so resulting in occasional Rx errors)? If you are sourcing the clock form an internal reference it may be quite inaccurate (several % deviation due to it being a trimmed RC oscillator, plus temperature dependency).

Although I don't think that it is a problem here, beware that th KL03 has only 2k or SRAM (if you are using the part on a FRDM-KL03Z board) and the UART's output buffer is quite small:

#define TX_BUFFER_SIZE   (128)

If the code were, however, writing more data than the buffer can accept it would result in loss of output (not character errors).

Regards

Mark

[enrico]

Thanks, Mark.

Yes, those are errors. I suspected it could be a matter of the LPUART speed. How can I measure that? Does the board output the LPUART signals through some pin?

I didn't have these errors when I was using PEx. I guess the only thing that has changed is the driving clock. Any idea why I can't use LPUART_IRC48M?

Thanks,
Enrico

[mark]

Enrice

The LPUART output is connected to the OpenSDA's K20 and so can be measured. They are also connected to J1 [LPUART0_TX = J1-2 / LPUART0_RX = J1-1].

What result do you get if you load the FRDM-KL03Z reference software from here? http://www.utasker.com/kinetis/FRDM-KL03Z.html
I think that that uses the IRC48M as LPUART clock source and I don't remember any inaccuracies with it.

Please could you tell me the version that you are using (or date of the developer's release) and I will test the LPUART on the same board with its possible clocks to verify that all are operating and how accurate they are.

Regards

Mark

[enrico]

Hi Mark,

I tried both uTaskerSerialBoot_FRDM-KL03Z_SREC.bin  and uTaskerV1.4.8_FRDM_KL03Z_RF.bin, and lpuart seems to print correctly on the terminal...

I am using Kinetis_17-6-2015. Thank you!

[enrico]

I just measured the output and:
-  when i select LPUART_IRC48M in app_hw_kinetis I have no output at all
- with LPUART_MCGIRCLK I get baud rate around 9100. If I set this number on the terminal I get the right output.

I've checked kinetis_UART and we have:

Code: [Select]

#if defined LPUART_IRC48M                                        // use the IRC48M clock as UART clock
            SIM_SOPT2 |= (SIM_SOPT2_UART0SRC_IRC48M | SIM_SOPT2_PLLFLLSEL_IRC48M); // select the 48MHz IRC48MHz clock as source for the LPUART
        #elif defined LPUART_OSCERCLK                                    // clock the UART from the external clock
            SIM_SOPT2 |= (SIM_SOPT2_UART0SRC_OSCERCLK);
        #else                                                            // clock the UART from MCGIRCLK (IRC8M/FCRDIV/LIRC_DIV2)
            MCG_C1 |= (MCG_C1_IRCLKEN | MCG_C1_IREFSTEN);                // ensure that the internal reference is enabled and runs in stop mode
            SIM_SOPT2 |= (SIM_SOPT2_UART0SRC_MCGIRCLK);
with:
 

#define SIM_SOPT2_UART0SRC_IRC48M    0x04000000                  // UART0 clock IRC48M (for KL03 and KL43)
        #define SIM_SOPT2_UART0SRC_OSCERCLK  0x08000000                  // UART0 clock source OSCERCLK
        #define SIM_SOPT2_UART0SRC_MCGIRCLK  0x0c000000                  // UART0 clock source MCGIRCLK
     

Everything looks fine there.

[mark]

Enrico

I have looked into this and have the following results:

1. Background: The standard Baud rate for the FRDM-KL03Z is 19'200 due to the fact that there is a large capacitor on the Rx line (higher speeds don't work without removing this).

2. When I test with IRC48M I have no problems so I can't directly explain why you have no output when using this.
However the FRDM-KL03Z is usually used with this setting:
#define RUN_FROM_HIRC                                                // clock from internal 48MHz RC clock
This means that the core clock uses this clock directly. If the core is operating, the IRC48M must be available.
In case you have used a different configuration or modified something it may be that the IRC48M is not enabled and then the LPUART would not be clocked if it were to be selected.
You could try adding this line of code:

Code: [Select]

MCG_MC = MCG_MC_HIRCENwhich will enable the IRC48M even when the core is not using it.

3. There are three reasons why the MCGIRCLK configuration is giving an inaccurate clock, which show that I hadn't tested it on this device before and assumed that it was compatible with other KL parts.
Normally the Fast clock in a KL part is 4MHz and the Slow clock is 32kHz. In this device the fast clock is 8MHz and the slow is 2MHz. This can be corrected in kinetis.h as follows:

    #if defined KINETIS_WITH_MCG_LITE
        #define FAST_ICR       8000000
        #define SLOW_ICR       2000000
    #else
        #define FAST_ICR       4000000         // NOTE - this already exists but the KINETIS_WITH_MCG_LITE not yet
        #define SLOW_ICR       32768
    #endif

The second reason is that the fast/slow setting is not being made (the default is for 2MHz but with the define USE_FAST_INTERNAL_CLOCK in app_hw_kinetis.h I would expect it to be 8Mz instead). Therefore the following can be added to the LPUART configuration so that is is set appropriately:

        #else                                                            // clock the UART from MCGIRCLK (IRC8M/FCRDIV/LIRC_DIV2)
            MCG_C1 |= (MCG_C1_IRCLKEN | MCG_C1_IREFSTEN);                // ensure that the internal reference is enabled and runs in stop mode
            #if defined USE_FAST_INTERNAL_CLOCK
            MCG_SC = MCG_SC_FCRDIV_1;                                    // remove fast IRC divider
            MCG_C2 |= MCG_C2_IRCS;                                       // select fast internal reference clock (4MHz [8MHz for devices with MCG Lite]) as MCGIRCLK
            #else
            MCG_C2 &= ~MCG_C2_IRCS;                                      // select slow internal reference clock (32kHz [2MHz for devices with MCG Lite]) as MCGIRCLK
            #endif
            SIM_SOPT2 |= (SIM_SOPT2_UART0SRC_MCGIRCLK);
        #endif

These two meant that you were getting 9600 Baud rather than 19200 Baud.

The third problem was however what lead to an inaccurate Baud of about 9000 and was due to an error in the Baud calculation.
This can be fixed by modifying
usDivider = ((((SPECIAL_UART_CLOCK/16/19200) + 1) * 2)/2);   // set 19200
to
usDivider = (((SPECIAL_UART_CLOCK/8/19200) + 1)/2);          // set 19200

With these corrections you will find that the MCGIRCLK is in fact quite accurate and the Baud will be close to 19'200 (I measured about 19'100 Baud, due to the IRC's tolerace)

Sorry about these errors in this case and I hope that you can also find out why the IRC48M didn't work.

Regards

Mark

[enrico]

Hi Mark,

Thanks for thorough analysis of the problems. I will test it again asap and follow your advices to fix the problems.

Best,
Enrico

[enrico]

Mark,

I had a chance to test the code.

About (3), now MCGIRCLK is working correctly at 19200. Just three questions to make sure I'm doing it right:
- KINETIS_WITH_MCG_LITE  was not defined anywhere, right? I defined it into config.h under the kl03 define.
- You wrote  "#define SLOW_ICR       32768", while the code was originally  "#define SLOW_ICR       32000". Would this create a problem?
- In kinetic.UART.h, I've adjusted the divider for SPECIAL_UART_CLOCK. Should I do the same in BUS_CLOCK and SPECIAL_LPUART_CLOCK?


About (2), I have #define RUN_FROM_HIRC. But still I can get any output out of the UART when i select IRC48. Really strange. I think I haven't changed any clock setting.

Thank you!

[mark]

Enrico

1. The define KINETIS_WITH_MCG_LITE may not be in your base code but it can be added anywhere (temporarily). Its best location is however in kinetis.h, where the following devices are presently known to require it:

// Clock setting/checking
//
#if (defined KINETIS_KL03 || defined KINETIS_KL43 || defined KINETIS_KL27) // devices with MCG-Lite
    #define KINETIS_WITH_MCG_LITE
#elif (defined KINETIS_KL02 || defined KINETIS_KL05)                     // devices with no PLL in MCG
    #define MCG_WITHOUT_PLL
#endif

2. SLOW_ICR is not required in your case. It is correct that I changed it recently form 32000 to 32768. The reason being that, although the user manuals call this a trimmed 32kHz, it is in fact trimmed to 32768 and so the more exact value gives better accuracy in case it is used (rare case though).

3. The cases that use BUS_CLOCK and SPECIAL_LPUART_CLOCK are OK, so don't need the correction.

As I wrote, when I tested the RUN_FROM_HIRC case it worked normally.
If you send me (attach it here) the version that you built (as binary, plus the map file) for the FRDM_KL03Z (also the version using MCGIRCLK  as reference) I can run both on my board and compare with the behavior when I build it. I may be able to work out the difference by checking some register settings.

Regards

Mark

[enrico]

Thank you, Mark.

I am attaching two zip files with bin and map files for the two different LPUART clocks.

Enrico