Freescale K20 and Teensy 3.0

[JCube]

I've come up with a preliminary port for the Freescale K20 50 MHz line (MK20D5) and board support for the Teensy 3.0. I've also added the usual LEB blinking demo. I say preliminary because I can compile all of the code I've written so far, but when I load it on my Teensy, the LED does not blink. Now I'm not really sure how to go about figuring out how to get anything working. I also doubt that I wrote the HAL and PAL correctly.

I really want to have a port of ChibiOS for the Teensy 3.0 so I thought I'd create it myself. However, I only started studying microcontrollers about a year ago in school. I'm currently a senior majoring in business software engineering. I was hoping someone on the forums here could help set me on the right path with this port. I do eventually want to implement all features of the MK20D5 but for now I'll settle for blinking the Teensy's LED.

My code is up on GitHub here:
https://github.com/JCube001/ChibiOS/tree/mk20d5_dev

The following are links to the GCC port, platform support, board support and a demo in that order:
https://github.com/JCube001/ChibiOS/tree/mk20d5_dev/os/ports/GCC/ARMCMx/MK20D5
https://github.com/JCube001/ChibiOS/tree/mk20d5_dev/os/hal/platforms/MK20D5
https://github.com/JCube001/ChibiOS/tree/mk20d5_dev/boards/PJRC_TEENSY_3
https://github.com/JCube001/ChibiOS/tree/mk20d5_dev/demos/ARMCM4-Teensy3-GCC

Resources I've used so far:
https://github.com/utzig/ChibiOS-Kinetis
http://www.pjrc.com/teensy/teensyduino.html
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=K20_50&nodeId=01624698C9DE2DDDA7&fpsp=1&tab=Documentation_Tab

[utzig]

I looked into some of your code right now and everything I looked into was quite right so I have no idea why it isn't working. I'll take a more thorough look into this on the weekend.

Fabio Utzig

[JCube]

Thanks for looking Fabio. I just tried to get the LED to turn on by using the following code.

Code: Select all

int main(void) {
    /*
     * System initializations.
     * - HAL initialization, this also initializes the configured device drivers
     *   and performs the board-specific initializations.
     * - Kernel initialization, the main() function becomes a thread and the
     *   RTOS is active.
     */
    halInit();
    chSysInit();

    /*
     * Creates the blinker thread.
     */
    //chThdCreateStatic(waThread1, sizeof(waThread1), NORMALPRIO,
                      //(tfunc_t)Thread1, NULL);

    int pad;

    for (pad = 0; pad < 32; pad++) {
        PORTA->PCR[pad] = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;

        GPIOA->PSOR |= ((uint32_t) 1 << pad);
        GPIOA->PDDR |= ((uint32_t) 1 << pad);
        GPIOA->PCOR |= ((uint32_t) 1 << pad);
    }

    for (pad = 0; pad < 32; pad++) {
        PORTB->PCR[pad] = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;

        GPIOB->PSOR |= ((uint32_t) 1 << pad);
        GPIOB->PDDR |= ((uint32_t) 1 << pad);
        GPIOB->PCOR |= ((uint32_t) 1 << pad);
    }

    for (pad = 0; pad < 32; pad++) {
        PORTC->PCR[pad] = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;

        GPIOC->PSOR |= ((uint32_t) 1 << pad);
        GPIOC->PDDR |= ((uint32_t) 1 << pad);
        GPIOC->PCOR |= ((uint32_t) 1 << pad);
    }

    for (pad = 0; pad < 32; pad++) {
        PORTD->PCR[pad] = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;

        GPIOD->PSOR |= ((uint32_t) 1 << pad);
        GPIOD->PDDR |= ((uint32_t) 1 << pad);
        GPIOD->PCOR |= ((uint32_t) 1 << pad);
    }

    for (pad = 0; pad < 32; pad++) {
        PORTE->PCR[pad] = PORT_PCR_MUX(1) | PORT_PCR_DSE_MASK;

        GPIOE->PSOR |= ((uint32_t) 1 << pad);
        GPIOE->PDDR |= ((uint32_t) 1 << pad);
        GPIOE->PCOR |= ((uint32_t) 1 << pad);
    }

    while (TRUE) {
        chThdSleepMilliseconds(1000);
    }

    return 0;
}

I used code from a Freescale example to try turning on and set for output every possible pad. No luck. I think this at least rules out the PAL as being the only issue. I really wish I had a way to step though and debug this board. I think I'll have to try soldering on wires for JTAG.

[utzig]

I got my Teensy today and tried your code and it didn't work. I had no luck yet fixing the problem but it seems to break in crt0 just before filling the stacks. That would suggest the problem is with the linker script but the script seems to be ok so I'm not very sure what it could be. I'll try to hook my ARM-USB-OCD to the board this week to make it easier to debug (supposing the interface does work at all with Kinetis).

To debug I had to use the LED!

To turn on the LED just put the following code before #if CRT0_INIT_STACKS in crt0.c.

Code: Select all

  *((volatile unsigned long *) 0x40048038) |= 0x00000800;
  *((volatile unsigned long *) 0x4004b014) = (unsigned long) 1 << 8;
  *((volatile unsigned long *) 0x400ff094) |= ((unsigned long) 1 << 5);
  *((volatile unsigned long *) 0x400ff084) |= ((unsigned long) 1 << 5);
  while (1) {}


If you put the code just after the #endif it doesn't turn the LED on which suggests the fault is happening right there in the stack filling calls which means there's an issue with the RAM.

Fabio Utzig

[JCube]

Nice, I was able to replicate turning the LED on. That's weird that as soon as the startup code touches the RAM then the MCU halts. I wonder what's really going on. I looked over my vectors.c file and I tried playing with the linker script but nothing I did could get past the CRT0_INIT_STACKS code. Let me know how using a real debugger goes.

As an experiment, I took a look at the bin files generated by both ChibiOS and Teensyduino. I noticed that the Teensyduino binary has startup code between the vectors and flashconfig. It also has a lot of 0x1F bytes towards the end of the file. The ChibiOS bin file has all zeros between the vectors and the flashconfig. It then has what looks like program code all the way until the end of the file. I don't know if this is important but these are the only differences I could spot in the two hex dumps.

[utzig]

Could you post the teensyduino based sources somewhere? I want to take a look at them without having to install the software.

Fabio Utzig

[JCube]

Sure, here's a link to my Dropbox.
https://www.dropbox.com/sh/aqs1wj5klhbqpd3/UfTnF68y4l

This is everything Teensyduino adds except for some binary tools like the Teensy loader and some external libraries that are also included in the installer.

[utzig]

Hi Jacob,

I finally got some free time to do some hacking on the Teensy. I'm attaching a patch to your git repo to make the led blinking work.

Basically what I've done is to configure PORTA correctly to enable clock input, which includes low-level and PAL configuration and I also disabled CRT0_INIT_STACKS in the Makefile. I don't know yet the reason why initializing stacks is causing a fault but I intend to find out.

If you still want to continue working on this port, I suggest you copy the serial_lld sources from my Chibios-Kinetis repo and make TestThread work. There are some little issues on your port which are teensy baggage, for example, initializing clocks for every subsystem. That doesn't make much sense for ChibiOS where each driver should initialize its clock. Apart from little issues I think this is quite good and I will integrate to my port when I get some time and hopefully make it upstream.

Att,
Fabio Utzig

[JCube]

Fabio,

I'll add your patch into my code. Unfortunately I can't test anything because my Teensy board died. I have no idea what happened but it won't show up as a USB device so I can't program it using the Teensy tools anymore. It seems like the MINI54TAN chip that sits in between the Kinetis and USB either just died or I was somehow able to brick it.

I'll clean up the rest of the code I've been working on but I may have to stop at that point to work on some other school related projects. Thanks for the help and do let me know what the problem is with the stack initialization!

Jacob

[colin]

Fabio,

I'll add your patch into my code. Unfortunately I can't test anything because my Teensy board died. I have no idea what happened but it won't show up as a USB device so I can't program it using the Teensy tools anymore. It seems like the MINI54TAN chip that sits in between the Kinetis and USB either just died or I was somehow able to brick it.

Hi Jacob,
It looks like the MINI54TAN is not actually involved in the USB communication, look at the Teensy 3.0 schematic. So I think the K20 chip is actually your problem. The USB data lines go to the K20 MCU and somehow the K20 must send the program to burn over to the MINI54 MCU, which then apparently programs the K20 using the K20's SWD interface on PTA0 and PTA3.

My guess is that the K20 actually has a minimal USB boot loader that must handle receiving the program from the Teensy loader program on the PC. But I don't know. I have had a similar problem, seemingly bricking (but I think I've ultimately recovered all of them) with my Freedom FRDM-KL25Z boards when I've been messing with system initialization and clocking, sleep modes (recommend putting a few seconds delay at program startup before the possibility of entering a low-power mode), or with accidental pin reassignments (make sure you leave RESET, SWD_DIO and SWD_CLK at their usual function).

Hope you get it figured out.