Continue reading »]]> I’ve noticed recently that the number of bits available in an ADC is slowly creeping up.  That makes me excited… until I look at the system accuracy.  How do you tell what you are actually reading with an integrated ADC?  You measure the internal voltage reference (IVR) usually.  Then you do some math to figure out what your rails are.  For single-ended measurements, this is usually ground and VCC.  So, what good is 12 bits of ADC accuracy if we only have six bits of accuracy with the IVR?  Yes, you heard me right, only six bits.  If you have an IVR with +/- 3 % accuracy, that ends up being about 6 bits of accuracy.  I’ll walk you through it.

Let’s say we have a 1.0 V IVR with a +/- 3% tolerance.  That means that it could be anywhere between 0.97 to 1.03 V, for a total range of 0.06 volts.  To find how many bits of resolution that gives us, we say 0.06 V >= VREF+/2ⁿ where n= number of bits of resolution and VREF- = GND.  If we have VREF+ = 3.3 V, that gives us n = -log₂(0.06/3.3) = 5.78 bits.  Working this backwards to verify we see that for six bits of resolution, the LSB is 3.3 V / 2⁶ = 0.052 V, which is less than our margin of error.  So, we have slightly less than six bits of absolute accuracy.

If you are using your ADC monitoring absolute voltage, any bits after six are waisted, just giving you a false sense of accuracy.  This can be dangerous when we optimize an algorithm for a particular device.  We may assume that the level of precision we have is also the level of accuracy we have.  This will bite us later when the lot-to-lot or device-to-device deviations in manufacturing suddenly move the IVR by 30 mV when we designed our algorithm for 12-bits of precision (which equates to 0.8 mV with a 3.3 V VREF+).

If you need more absolute accuracy, you can get an external precision voltage reference to connect to VREF+.  Depending on your application you may be able to depend on the stability of VCC and assume what it is.  When you are running of a battery and VCC can change, that is not an option.  Now you know.

Continue reading »]]> I had an interesting problem show up when I was working on a project at the beginning of the year.  It involved an Analog Devices Blackfin 51x series processor.  We went to transition to their new IDE and that’s when we started noticing problems with the Flash RAM.

The Backstory

I was bringing up a new board with an Analog Devices’ Blackfin 514 on it the last part of 2012 and the first part of 2013.  We got the code working and got it programming the flash RAM and booting from it using their VisualDSP++ IDE.  Since this was a new design, we wanted to transition to their Cross Core Embedded Studio (CCES) that is based on Eclipse.  We got the base program transitioned over and then tried programming the flash RAM and booting from it.  That didn’t go so well.  I reprogrammed it and verified what was programmed.  Let’s try this again… and again, the old program ran.  We swapped back to VisualDSP++ and it didn’t see the new code.  What gives?  To understand my level of frustration, realize that this was a period of more than aweek as it was a 24 hour round trip for answers to tech support questions via India (I think, the replies liked to show up at 3 AM MST).

… and now, the rest of the story

Thank you for the introduction Paul Harvey.  We slowly got the issue escalated.  I sent traces from my oscilloscope of the memory lines.  I was finally talking with the author of their flash programming driver.  I sent memory dumps back and forth from VisualDSP++ and CCES.  We did that a few times and had some of their engineers look at our schematic.  We finally had a lead.  We had based our design of the BF518 Ez-board.  If you look at their documentation, page 94, zone 2A, there are several pull-up resistors on the AMS lines between the switches and flash RAM.  When we designed the board, we assumed thought that the pull-up resistors were there to keep the lines from floating when they were disconnected from the processor.  It turns out that when the processor first resets, some of those lines are not configured as AMS lines, but are floating.  Alright.  Now we know that is a problem.  If that is the case, then why were we able to program the flash RAM in VisualDSP++ successfully.

So, why did VisualDSP++ successfully program the flash RAM?  It turns out that when the code for the flash driver for the BF518 Ez-board was designed just for the BF518, not the BF51x series.  So, when we went in and changed it to compile for the BF514, there was a preprocessor directive that no longer compiled in the code to set all the AMS lines as active.  That was the second “wrong”.  We were lucky that with some of the AMS lines floating, they reliably floated in a particular direction so we ended up programming and reading the same 1 MB block of flash memory… which was not actually the first block of flash memory.  We didn’t notice this because our program was small enough that we didn’t need more than the one block of memory.

When transitioning to CCES, we fixed the wrong in the flash RAM driver which caused our error to show up.  We soldered on the pull-up resistors and things started working with CCES… and failing with VisualDSP++.  We figured out what needed to be changed so the correct portions of the VisualDSP++ driver would compile and work.  Things were good after that.

The moral of the story is, “Yes we put those there for a reason, but not the one you think.”

Continue reading »]]> I previously wrote my review of the Freescale KL25.  Since then I’ve finished my first design with the KL25. The second spin of the board will see several of the peripherals and pins rearranged.  Most of this has to do with things that I glossed over in the documentation desire to get the product to market.  None were killers, but required some work-around or are being changed to improve functionality.  

Keeping I/O Busses Active

To get the lowest current you try and shut things off.  Well, you only have a finite number of choices for clocking your peripherals.  This becomes especially tricky if you are using the very low power run (VLPR) mode.  First off, pull up table 5-2 (p. 121) from the reference manual.  This shows you the clocking options.  Now, pull up table 7-2 (p. 144) to see which peripherals and clocks are available for the low power modes you want to operate in.

SPI

The first question is, do you want to have the SPI bus active while in a stop mode?  If so, we have to use partial stop mode (PSTOP2 where the bus clock is active) and SPI0, which is clocked off the bus clock.  Otherwise we can use SPI1 which is clocked off the faster system clock, but is only operable during run or wait states.  The next consideration, will be the desired speed, especially during VLPR mode.  If we are going to use VLPR mode, SPI1 can run at 4x (in reality, closer to 5x) the speed of SPI0 due to limitiation on the bus and system clocks in VLPR mode.  Either SPI bus will work as a slave in stop and VLPS modes, but the bus speed limits are half what they are for masters in the same mode.

UART

Do you need more than one UART?  If not, just use UART0.  It has more clocking options and there are no downsides compared to UART1 or UART2.  If you need more than one UART, the question becomes what modes do you want your UARTs active in?  There is one low power UART (UART0) that can be active in stop or VLPS modes.  So, the first question is if you need multiple UARTs active, which one will you need to monitor more than the others?  This device needs to be hooked up to UART0.  If that is not an issue, are you using the VLPR mode?  If so, UART1 & UART2 have a much lower line speed in these modes compared to what UART0 can do.

I2C

Do you need more than one I2C bus?  If not, just use I2C0, as it will work in PSTOP2 mode.  (I haven’t confirmed this.  The documentation leaves me a little unsure here.)

USB

What I found out is there is not an internal way to see if VUSB+ is hooked up to the VREGIN pin.  So, throw a voltage divider on the board and hook it up (the divided voltage) to a pin so you can sense if there is a USB connection.  I initially started this project thinking I would use the USB port for communications, but ended up just using it for charging the battery.  That means that I was not running any of the USB stack on the MCU.  The next spin of the board I plan on putting a KL15 on it instead, since I am not actually using the USB interface, except for charging.

GPIO Interrupts

The first thing I found, and mentioned in the comments in the prior article, only GPIO port A & D have interrupt capability.  On top of that, if you are using any of the low leakage stop modes, if you want to interrupt on a GPIO, it needs to be connected to a pin that is connected to the low leakage wakeup unit (LLWU).  There are only two pins which are able to interrupt while awake or in the low leakage stop modes.  These two pins are PTD4 & PTD6.  They are available on all packages.

Of note is PTA4.  It defaults to NMI.  If you plan on using this as an input that is not the NMI, make sure that you put code before main() to change the pin setup.  If you wait until main to do it, you may trigger the NMI before you get to main() and wonder what in the world is going on.  The same goes for PTA20, which defaults to RESET_b.

If you decide you need to use the pins that SWD is on, don’t forget to double-check your circuit so that you do not hurt either the programmer or target device when trying to program.  Yes, you already know this, but take a minute and check it for me.  You’ll thank me one of these times.

ADC

If you are using a package that has external VREF +/- pins, make sure to hook them up.  The documentation alludes to multiple options for ADC references, but I was unsuccessful using the alternate VREF setting.  I assumed that the alternate VREF setting was internal connection to VCC & GND.  This isn’t a big deal as VREF +/- are right next to VCC and GND pins.

Choosing Pins

Now that we’ve talked about peripheral selection, here’s the general order I would use for selecting what goes on which pins:

1. Which signals need to be on GPIOs that need to interrupt while running and in low leakage stop modes.
2. Serial busses – SPI, UART, I2C
3. other internal peripherals (ADC, DAC, comparitor)
4. Input GPIOs (put these on extra pins on ports A & D)
5. Output GPIOs

While deciding what goes where, remember, you have to route all these traces so try to keep them as short as possible and away from each other as much as possible.  We don’t need to add another two layers to the board when it can be avoided.

Closing Thoughts

Overall, I am pleased with what I have seen out of the KL25 series of MCUs.  I’m interested to poke around with the KL05 series to see if it’s worth replacing some PICs or MSP430s for low end designs.  I’m not convinced of that, just because of the coding complexity of bringing things up (more time spent with init code) and low power current with SRAM backed up.  We shall see.

Continue reading »]]> One of the projects I’m working on I chose to use one of the new Freescale KL25 MCUs.  They have an ARM Cortex-M0+ core and lots of peripherals to boot, including ones specifically designed for low power usage.  Below are some of the reasons why I chose it, and what my experiences with it have been.

Why the KL25?

Initially when I chose the KL25 my criteria was an MCU with a few KB of RAM for text buffers and a timer/counter that can operate as a counter with almost everything else shut off on the chip.  I can get quite a bit of RAM on the KL25 and its low power timer can operate in counter mode with almost everything else shut off on the chip.  The other thing it has going for it is that it has an ARM Cortex core in it.  A proprietary core is a drawback for me when ARM has the one ring core to rule them all.  I don’t have to learn a new interrupt controller every time or a new whatever.  Don’t get me wrong, everyone has their own peripherals, but as far as the different Cortex cores go, it’s just remembering which instructions are in which core.

Initial Experience

I picked up one of the FRDM-KL25 boards to give it a dry run.  The IDE I used was the CodeWarrior 10.3 beta.  First up, the Processor Expert tool was a life saver.  The clocking on the KL25 is rather involved and it takes up to three different clock modes to get to your final mode.  The complexity comes with the flexibility the processor provides.  Processor Expert is great, even if all you do is cut the code out that it generates and paste it into your own application.  Without it, I don’t know if i would have made it past setting up the clock.  After that it was a matter of setting up the different peripherals and going.  I didn’t use DMA or interrupts for my first trial, just polling.

Onto a Custom Board

After it working for our initial prototype, we did up a custom board with the KL25 on it.  The only issue I had there was that my clocks wouldn’t start.  It turns out that I fried the MCU the first time I powered it up.  Four dead chips later I figured out that the example I was coping the RTC code from used a crystal, not an external clock chip.  So, whenever I “enabled the oscillator,” the MCU and external clock were fighting who was driving the CLK_IN pin and it killed the clock.  It turns out that step can be omitted when using an external clock.

Peripheral Thoughts

I was a little surprised that only two of the five GPIO banks are capable of interrupts.  I had expected all of them to.  That just meant I had to be a little more careful with what i attached to which pin.

The KL25 has an up to 16-bit ADC.  However, the internal voltage reference is only good to +/- 3%.  That gives me six bits of accuracy for the voltage reference… which gives me six bits of absolute accuracy for a 16-bit measurement unless I attach an external voltage reference that is more precise.  I will say that I am happy with the temperature I am getting out of the internal temperature diode.  The first time I programmed it up I got within about 0.1 °C of what I expected.  One thing I will nit-pick about the ADC documentation is the “alternate” voltage reference that can be set.  I tried using it since I did not connect the external analog power pins initially.  I was able to read the internal voltage reference and temperature diode just fine, but external readings were way off.  After I connected the external analog voltage pins, VDDA & VSSA, the external readings were good.  I like that the ADC will do reading averaging by itself without intervention from the core.  I tell it to get me the reading from a channel and put the core into a wait state until the ADC tells me it’s done with its readings.

Conclusion

I like the KL25 and hope that it works out well in the long run.  To finesse the lowest power out of it takes some doing and I figure my code base will undergo several revisions as I push to get the current draw down as low as it can go.  A lot of that will be mastering the clocking of the chip and putting enough intelligence into the program so that it will change the peripheral clocking when the core is put into one of the low power modes.

Continue reading »]]> … or how to edit a .hex file instead of recompiling it for every option.

I had a product a while back where the customer needed to program it, but we didn’t want them to have to hassle with compiling it for every (10,000+) permutation.  I had a whole build system set up when this was just a few hundred files that would do all the compilations for me (thank you python!).  That was now out of the question.  There were a few hurdles to do this on a PIC, but we achieved it

Outsmarting the Compiler

We use the CCS compiler for our work on the PIC16 processor.  There is a handy compiler tag to tell it where to put your constant variable, #org StartLocation, StopLocation.  Simple right?  right?  Not so fast. If you just define a constant variable, refer to it once when loading it into the actual variable in RAM, the compiler will compile it out in the name of speed.  How nice.  To outsmart the CCS compiler, one had to create a one element array and initialize it as so:

Now we have the value stored in flash memory as part of the program.

Overcoming the Architecture

One interesting tidbit of heretofore insignificant trivia is that the PIC16 uses 14-bit words for instructions.  This now becomes significant because we are saving our variable in code memory.  How do we access it?  How does it show up in 14-bit memory?  It shows up as the lowest eight bits of a 14-bit word.  So, our example four-byte unsigned int32 takes up eight bytes of space with every other byte 0x34.  The higher byte is actually an opcode (RETLW) that returns the lower byte.  The CCS compiler does not access the memory location so much as run the code at the location.  As part of this method there is some overhead associated with storing a value.  There is a one word prefix added to the amount of memory required.  Let me show you how this works.  Say we are trying to store the value 0xFEDCBA98 (4,275,878,552 unsigned) into memory.  The value is stored in memory Little Endian style, so the lowest byte is at the lowest address.

Now that we’ve got that figured out, let’s put it together:

Notice here that I am stating the length of the array, not the variable index of the array.  I am not assigning a value to array element ’1′, but initializing an array of size one.

Editing the Hex File

To edit the hex file we need to find the memory location we care about and write to it.  One thing to note is that the memory location listed in the .hex file and the memory location listed in the #org is not the same.  The value in the intel hex file is actually twice the value listed in the #org statement.  Why?  Because the intel hex file is addresses bytes, but the #org addresses 14-bit words.  The intel hex file is a paged file format, so take that into account when looking up addresses.  Now we know the address we need and what to look for in memory, so what’s left?  Making sure we get the CRC on the .hex file correct.

Embrace and Extend or, a custom CRC

At this point we have edited our .hex file and want to load it onto our firmware.  We can do that using the ICD-64U previously mentioned using their handy-dandy command line tool… but it doesn’t like the checksum.  Wait you say, there isn’t a checksum as part of the intel hex file format?  CCS was kind enough to add one for us.  The last line of the file reads: ;CRC=5FA2  CREATED="11-Dec-12 12:13".  The CRC is run on all lines proceeding this line in the file.  The following code, in C#, will generate the CRC for the file:

There is also an option in the command line tool to ignore the checksum, but it is generally not good form to have warnings thrown at the end user that occur all the time.  If you’re wondering why I chose C# for this code it’s simple.  The programmer runs on windows and it was the easiest way to create it and get it to work.  I don’t want to have to pack python libraries with it, or have them install the GTK framework, or wxWindows.

Closing Remarks

That gives enough information to get you going.  I hope this just saved someone a week of learning the hard way… and a lot of back and forth with CCS tech support.  If you need some help filling in the gaps, I happen to know an engineer who can help.

Continue reading »]]> We had a bug that just wouldn’t go away. Sometimes it would show up quickly, sometimes it would show up after the code had been running for a few days… but it would show up. What’s the programmer to do?

The Setup

So here’s the background. We have an ARM Cortex-M3 MCU that we are using as a controller and IO processor for a device. It’s coordinating about 4 serial connections. Luckily, only two to three of those are active at a time. We had the proof of concept code running without hangup for over a week. Add a few more functions and things look OK… then we started getting lockups after the program ran for a few days. The first temptation was to ignore them because they were happening after the device was running for a few days. People wouldn’t use it that long in the real world, right? Then we had one of the lockups occur after 9 hours. That was a little harder to marginalize… so down the rabbit hole we go.

Initial Diagnosis

When I’d stop the MCU in the debugger, it was reliably stopped in the same location in memory. A stack trace was not intuitive as well, since the debugger couldn’t figure out which subroutine we were in… because we were outside programmed memory. It felt like the Star Trek: The Next Generation episode where they traveled past the edge of the universe. After some slight changes to the code to aid in debugging, it now started hanging at another address reliably. I figured there had to be a reference I had wrong in the code that was causing the jump to nowhere, but how to find it?

A week of code review didn’t turn it up. I thought it might have something to do with a stack overrun (I had this problem when using sprinf() before) so I pumped the stack up to 3x what I thought it needed. I even went to the trouble to initialize the stack so I could see what was used and while instructive, it showed that stack overflow was not the culprit.

But where does it start?

Trying to piece the stack trace together manually, it looked like the code was locking up during a delay loop. Statistically, that was to be expected since that’s where the processor spends 90%+ of it’s time. So, was it correlation or coincidence? Was the address it was locking up the first place it went off the reservation, or just where it got stuck. To help with this I made sure that whenever I programmed the MCU, it cleared all the flash memory, not just the portion I was using. That changed where the program was hanging. Now it was hanging on a jump to the end of the 32-bit address space… where I didn’t even have memory.

At this point I’m starting to rip out whole modules of code to try and narrow down what is occurring. We’re two weeks into trying to track this bug down. It’s still hanging. Ripping out sections of code hasn’t solved anything. It did lead to a clue. When I activated the SysTick interrupt I now had the processor reliably hanging less than a second after I enabled interrupts on the MCU. So, this is interrupt related. Hmmm…

On the Trail

I went and checked my vector interrupt table (VIT) and it looked good. I’m pretty sure it is the interrupts, but what is going on here. How am I getting sent to the end of the know address space when I’ve looked at the actual values being stored, which are all legit. How to further narrow things down?

I went looking for an opcode I could write across all unused memory to further figure things out. After a lot of digging I found an opcode (breakpoint, 0xbexx) that would pause things when debugging. I went into the linker script and had all extra memory filled with its opcode. Now let’s see where that gets us.

A Break in the Case

When we started up the code this time, it did indeed halt the code…. at the same address as the value of the opcode I had just overwritten everything extra with. So… we’re interrupting and jumping to the address all my unused memory is pointed at. At this point an epiphany occurred. While I hadn’t made many changes to the c code for the project, I had changed the location of things in flash memory so I could do boot-loading. I had also changed where I stored the VIT. Maybe I was onto something here? I did some digging and while relocatable, I have to tell the MCU where I relocated it to. The software is not smart enough to do that for you. Some of the built-in libraries may do that for you, but if you’re moving things in the boot loader, good luck.

The Fix is In

So, was it that simple, set a register and we’re good? To test I found said register and set it before any interrupts were enabled… and let it run… and run… and run. After about four days I declared it good… and then let it run over the weekend just to be sure.

The moral of the story is, just because you tell one piece of software (the linker in this case) what you are doing, don’t assume that the other piece (the compiler) or the hardware is smart enough to figure out what you are doing. For the gory details see the e2e.ti.com thread. I hope that this helps.

Continue reading »]]> Sometimes you end up having to program a device with many different types of firmware. For a project I’ve used PICs on, this was the case. Here’s how to setup things so that all it requires is two clicks to load the firmware from windows explorer.

This trick uses the CCS ICD-64U programmer (it will probably work with any of their programmers). We first create a batch file (with a nice name like PIC.bat) in our favorite text editor that calls the loader and then pauses so we can read the output. You may have to adjust the location of the executable depending on your installation location.

Next copy the batch file into %APPDATA%\Microsoft\Windows\SendTo and you’re done. Now find a firmware file, right click on it and then you should have the batch file listed as an option.

Continue reading »]]> Recently I’ve had a project that required precompiling the firmware for a device so that the end user could program the device, but not have the source code. We’re not talking about a few versions of the code, but almost 1000. This is something that no person would want to do, especially since it would have to be redone every time the source code changes. Python to the rescue. It was simple enough to write a program that would copy the source code, change a bit of information in a header file, compile it and save the binary to the appropriate location. Controlling other programs is pretty easy with the subprocess module. That’s great and all, but doing it single-threaded, that’s so 90s. Python makes multithreading pretty simple using its multiprocessing library. The trick is not stepping on any toes when you do it.

For starters, I have eight (okay, four hyperthreaded) cores. Since I still have to use the system, I set up a pool to use up to six threads. The object that is returned from the pool.apply_async() function was arrayed to keep track of all the desired processes. This is because in the time it takes for a dozen of the compilations to finish, I’ve already queued up almost 1000 compilations. At this point the main python thread just sits there checking to see if a task has completed and stores the output information.

Gotchas

Timing

One of the problems that I encountered was that of making sure that I wasn’t copying the source code into the same place to compile. To create unique directories I tried to timestamp them down to the microsecond. That would have worked wonderfully… except that the time stamp I was getting out of the time module in windows was only granular to about 10 milliseconds. That caused some of the threads to fail because they were trying to use the same directory. I found another way to uniquely name the directories and then we were good./p>

Keeping passed data safe from other threads

You’re familiar with the terms shallow and deep copy, right? Do you know when each one is done in python? Most of the time it is a shallow copy. Well, when you pass the same dictionary, with slightly different parameters, as the argument in each pool.apply_async() call… you can see where this is going. By the time the dictionary could be acted upon it had been changed in the main thread… many times. Luckily, we have the copy.deepcopy() function to save the day. I just made sure that we did a deep copy of the dictionary before passing it and things went much better.

A skeletal example

The acutal code was written for a client so I will only show a prototype for you to use here

You may be asking why I didn’t use the map() function of the pool. The reason is that the calculations involved in each iteration were sufficiently complex that I didn’t want to wait until I had all the calculations done for each permutation of code before starting compilation. The first few versions of the code had the calculations necessary to figure out the code changes taking as long as the compilation.

Continue reading »]]> Over the last few months I’ve been working on projects using PIC microcontrollers. At first I had a rather negative view of the PIC processors. Since I started coding on them, I have come to realize that it is the compiler that I have issues with much more than the hardware. The compiler we’ve been using by CCS is designed to get projects up and running quickly by abstracting the hardware from the coder. So, instead of directly writing to the registers, you call one of their functions. We’ve found this works well when it is a mature processor and when we’re not trying to do too many things at once. Where we ran into lots of frustration was with new processors. We thought we had the code written correctly, yet it wasn’t working. Now instead of just having our code and hardware errata to look at, I also had to figure out what the CCS code was doing… which means slogging through the disassembled code and looking up the mnemonics for the different assembly operations.

Now, you need to understand where I come from. I’m a Professional Engineer. When I vouch for something, I’m saying that it works. When I have the black box of a intrinsic compiler functions, it makes me a little less sure about what is occurring. That’s one of the reasons why I like the MSP430. TI does a very good job of letting me know what’s going on with the chip. There’s not much left to the imagination when using it. The analog functions are well documented and there are good code examples. The Stellaris line of ARM Cortex-M3 chips tries to make both camps happy. It has good documentation of things, but it also comes with a large driver library that encapsulates many of the functions for an engineer to rapidly program on it.

My beef with embedded processor abstraction through libraries or intrinsic functions is that it usually doesn’t keep up with the latest processors and that it is too easy to do something that modifies something else and then you don’t know where the problem is being generated because the functions work separately or in a different order. Oh, and they take more memory, on memory constrained processors. What’s your experience?

Continue reading »]]> For those of you run multiple operating systems, you may have run across the problem where the filenames on one are not valid on the other. Specifically I’ve had that problem when using NTFS filesystems between Linux and Windows. The NTFS3G drivers on Linux will allow characters in the file names that windows doesn’t like. To solve this, I wrote a quick python script that will make the filenames windows acceptable. Enjoy.

windows_rename.py