Thanks to Erich and FRDM-K64F!! :)

It has been a long time since I wrote my last blog. I really want to apologize to you all for the delay, but I was busy with another project about the competitive analysis of Freescale with our competitors. I hope I can provide you guys later with some important findings from my research.

Well as far as my project for neopixels using FRDM-K64F is concerned, Erich wrote the wonderful tutorial for all of us to turn on the NeoMatrix. I tried my hands on that and I was indeed able to turn on the board but not in the way I wanted it to. 😦 So, it turns out that I got few LEDs turning blue or some turning green. I asked Erich about it and I got to know that it is because I screwed up with the timing signals. I was using an oscilloscope and not a logic analyzer but Erich’s recommendation was to use the Logic Analyzer. This was the result of my experiment following Erich’s tutorials.


The Hardware

With the oscilloscope, I tried to time the signals but could not do it in a better way. I will be working on it later this summer and probably through the fall, because the good news is that I can stay with Freescale for next fall as well.


Timing signals

Working on this project helped me a lot for working on another project for competitive analysis of Freescale with other semiconductor companies. I am actually able to analyze the DMA (Direct Memory Access), EDMA, FTM (Flex Time Modules) concepts and get my hands on them. This really helps if you want to compare the features with other microcontrollers. I think MCU on Eclipse is the great platform by Erich for all the tech savvy people around the world to get some practical experience of the Microcontroller boards by Freescale.

In my next blog, I will be trying to come up with the right signals so as to light up the board as required. After that I will be working on taking this project further as I talked about the signboard.


5 thoughts on “Thanks to Erich and FRDM-K64F!! :)

  1. Hi Manya,
    sorry to read that you still have problems. Using an oscilloscope for sure is fine too! It is only that I’m using most of the time a logic analyzer as it is more porable (I’m travelling to work with hardware using public transportation) and logic analyzers can be easier to use.
    Here are some tips I can give:
    – make baby steps: I see in you picture you try to turn on all LED’s? Just go with one first. Send 24bit of data to the LED stripe, it will be consumed by the first LED.
    – send the 24bits, then wait for at least 50 us or more to latch the bits. Use the debugger to send the 24bits, then halt it to see what happens.
    – use a simple pattern of bits: 8 bits high, 8 bits low, 8 bits high. Count them in the oscilloscope/logic analyzer if they are all there
    – check the signals before the level shifter and afterwards: are all bits there?
    – check the timing of the signal: what is the frequency? how many us are the bits is high/low? Does it match the specification?
    – check the voltage levels (here the oscilloscope is great!) of the signals: they shall be 3.3V to the level shifter, 5V after the level shifter.
    – keep the wires short: few centimeter (or one inch) to the level shifter, few centimeter (one inch) from the level shifter to the first LED. From the picture you share this looks ok, but I cannot tell for sure.
    – not sure about your 5V power supply you use. For a few LEDs, you can use the 5V from the FRDM board to eliminate that variable. The 5V is available on the Arduino header near the GND and 3.3V pins.
    – it would be good if you could post a high-resolution picture of what you see on your tektronix (again, best just one pixel) with clear labels/information what the signals are, and what the scale/division.

    I hope this helps!


  2. Hi Manya (and Erich of course ;-))!

    As Erich has already covered DMA & Timers it is perhaps a good idea to go a slightly different way with your tutorial.

    One approach that works very well is to use SPI, you can get good results without the need to use DMA at all, the trick is to set SPI Clock to a value of 2.5MHz (The real frequency will be a little less when you use a k64f board that runs on internal RC-Osc speed of 20MHz) and to set SPI to 16Bits mode.

    The only extra Hardware you will need is a cheap 74HCT14N Chip as an inverting Level shifter or a Transistor/MosFet to do the level shifting from 3.3 to 5V. The rreason for this is that the SPI signal needs to be inverted as the WS2814B LED’s are active high and the SPI is active low.

    With this configuration you can use a group of three bits that are about ~0.42 Microseconds ‘wide’. This is just the value needed to make the ws2812b work.
    so sending 110 via SPI means that you have a signal that is 0.84 Microseconds high and 0.42 Microseconds low. The resulting length of the signal is 1.26 Microseconds, so all is very well within specifications.
    You can now either use the 16 Bits of the spi to send only 1 correctly timed sequence for one bit to the LED’s, but as timing matches so well you can send up to 4 bit-sequences within the 16Bits.

    If you are interested I can send you demo code and some Logic Analyzer Screenshots that help to better understand how this SPI approach works.



    • Hi Michael,
      thanks for providing help! I have seen that approach with SPI using an NXP LPC810 ( which is a really interesting one, especially for driving a single lane of LEDs. Picture of the signals: GitHub code is here:
      What I see as a challenge with this approach is that the SPI data phase cannot be interrupted. So the SPI needs to run with the very highest priority, otherwise the protocol does not work. Or are you using a different approach?


      • I have read a very interesting article on the inner workings of the ws2812B here:

        the main fact is that it is only relevant to get the width of the high phase right, it does not matter how long the low phase takes as long as it it in the range of 0.4 to 8 Microseconds.
        Keeping the line low for >8 Microseconds makes the chip take over the shifted in bits.

        Here’s the output of the logic analyzer, showing original MOSI output, the inverted output that gets sent to the LED’s and the clock:

        I am using the fifo of the spi line, this makes timing even more relaxed as you only need to suppy 6 16-bit values within 40 Microseconds to transfer data for one LED. Once all bits for all attached LED’s are transfered the spi does not need to get feeded anymore, the data will automatically end up in the LED’s.

        So I did not even bother to use DMA. Driving 100 LED’s will take 4ms, that is a refresh frequency of 250Hz. that can get reached in theory which is more than sufficient for animations.

        I cannot judge if those data rates do imply that SPI does need to run on highest priority, perhaps the numbers provided help you to make this decision. But loading one uint16 every 24 Microseconds does not sound like an impossible task for DMA, but there I am lacking some experience.


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.