FRDM-KL03Z debug, LED and SPI

[mark]

Hi Enrico

The problem is that the internal boot loader is enabled and this causes some conficts. It also delays the start of the board by several seconds.

In app_hw_kinetis.h you can find the configuration in your version to be as follows:
#define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION (FTFL_FOPT_BOOTSRC_SEL_ROM | FTFL_FOPT_BOOTPIN_OPT | FTFL_FOPT_FAST_INIT | FTFL_FOPT_LPBOOT_CLK_DIV_0 | FTFL_FOPT_RESET_PIN_ENABLED | FTFL_FOPT_NMI_ENABLED)

As you can see, the ROM loader is selected.

If you change this to
#define KINETIS_FLASH_CONFIGURATION_NONVOL_OPTION  (FTFL_FOPT_LPBOOT_CLK_DIV_0 | FTFL_FOPT_RESET_PIN_ENABLED | FTFL_FOPT_BOOTSRC_SEL_FLASH | FTFL_FOPT_BOOTPIN_OPT | FTFL_FOPT_NMI_DISABLED)
it is disabed and won't disturb the UART. In addition, the board will start immediately after a reset.

Regards

Mark

[enrico]

Thanks Mark! Now it works with IRC48. I am pretty sure I didn't change that setting. For my understanding, what is the purpose of this setting?


Moving forward with my implementation, I am able to send and receive data to and from an FPGA through SPI. As a next step, I want to set an port type interrupt coming from the FPGA. I've started from the nRF24201.c code for the SPI setting and transmission. Now I am trying to reuse that code for setting the interrupt as well. However, as soon as I configure the interrupt, the system just doesn't work. No blinking led, no UART, no SPI. I guess it get stuck somewhere in the port initialization (a memory issue?).

As a note. I've observed this behavior with the original code as well (before I started implementing my changes). To make it works, I always had to comment the interrupt configuration.

Any idea on that?

This is my initialization code (exactly as in RF24201.c):

Code: [Select]

INTERRUPT_SETUP interrupt_setup;                                     // interrupt configuration parameters
    interrupt_setup.int_type       = PORT_INTERRUPT;                     // identifier to configure port interrupt
    interrupt_setup.int_handler    = fn_nRF24L01_interrupt;              // handling function
    interrupt_setup.int_priority   = nRF24L01P_IRQ_PRIORITY;             // interrupt priority level
    interrupt_setup.int_port       = nRF24L01P_IRQ_PORT;                 // the port that the interrupt input is on
    interrupt_setup.int_port_bits  = nRF24L01P_IRQ;                      // the IRQ input connected
    interrupt_setup.int_port_sense = (IRQ_FALLING_EDGE | PULLUP_ON);     // interrupt is to be falling edge sensitive
    fnConfigureInterrupt((void *)&interrupt_setup);                      // configure interrupt

Thank you,
Enrico

[mark]

Enrico

The KL03 has a small ROM whih contains a Freescale boot loader. It can be used for programming a new device (without need for a debugger) and later for updates in the field.

When this is enabled (default chip state) it will configure some peripheral and pins (depending on chip and loader) which may cause problems with code that is not expecting this. The loader can however be disabled so that the processor starts immediatyl, without first passing through the loader.

In the developer's version from 17.6.2015 it was enabled (presumably to test something) and had this effect on the KL03's UART in the IRC48M clocking case. Initially I checked the wrong version so missed this but when I saw how long it took your binary to start I realised that it must be due to the loader. (In fact I don't now why there is the interference and I still need to find out why so that the loader coudl be used if ever needed).


I just checked IRQ operation on the KL03 by enabling IRQ_TEST in Port_Interrupts.h. This worked correctly on PTB3 (and I also checked on PTB7, which I think your code is using).
Is is possible that you have a high frequency signal on the input so that the IRQ fires all the time?

As comparison, you could try a different pin (to ensure that it is not pin related) or delay enabling the interrupt to ensure that the board is otherwise running normally up to that point.

Regards

Mark

[enrico]

Hi Mark,

By default I am using PTB3. The problem is happening independently from the point where I configure the interrupt.

I did some debug and the code is getting stuck here

Code: [Select]

#if defined USE_MAINTENANCE && (!(defined KWIKSTIK && defined SUPPORT_SLCD))
        fnInitialisePorts();                                             // set up ports as required by the user
#endif
I commented #define USE_MAINTENANCE in config.h and now it works. I am pretty sure it was running out of memory.

Thank you,
Enrico

[mark]

Enrico

Since the KL03 has very little memory (2k SRAM) there is always a risk of error occuring when additional code is added which causes the stack to overlap with variables/heap.

This could be an explanation and needs to be monitored throughout the a project development: see the memory functions
fnHeapAvailable()
fnHeapFree()
and
fnStackFree()
which can be helpful in the process.

Regards

Mark

[mark]

Enrico

I did some checking of the IRC48M LPUART clocking issue with the internal boot loader (in ROM) enabled.
On the KL27 I didn't have any problems with it but on the KL03 it turns out that the LPUART clock is selected by the boot loader and then the operation used to select the IRC48M failed since it was assuming that the register has the values after a normal reset.

To allow it to work after the boot loader has operated the IRC48M selection can be changed as follows:

SIM_SOPT2 |= (SIM_SOPT2_UART0SRC_IRC48M | SIM_SOPT2_PLLFLLSEL_IRC48M);

changed to

SIM_SOPT2 = ((SIM_SOPT2 & ~(SIM_SOPT2_UART0SRC_MCGIRCLK)) | (SIM_SOPT2_UART0SRC_IRC48M | SIM_SOPT2_PLLFLLSEL_IRC48M));

This first masks out the clock selection field so that the resulting value is correct.
There is a similar expression for LPUART1 that can be modified too (although LPUART1 is not available on the KL03).

SIM_SOPT2 = ((SIM_SOPT2 & ~(SIM_SOPT2_UART1SRC_MCGIRCLK)) | (SIM_SOPT2_UART1SRC_IRC48M | SIM_SOPT2_PLLFLLSEL_IRC48M));

Regards

Mark