Pololu Robotics & Electronics
My account Comments or questions? About Pololu Contact Ordering information Distributors

Wixel upgrade - more ROM capacity



We have been using the Wixel for years now as a MCU for an IoT device. It has performed excellently for a variety of functions. However, now with ~2000 lines of code, we’re constantly fitting against the 29kB ROM limitation.

We’ve spent quite a bit of effort to streamline the code, minimising globals, printfs, variable sizes etc. Any advice specific to the Wixel or SDCC to further reduce the ROM consumption?

Beyond the core TI CC2511 chip which itself does not come with a version higher than 32kB flash, is the Wixel software/bootloader compatible with any other TI chip?

Many thanks,


Hello, Fiachra.

I am glad that the Wixel has worked well for you.

The Wixel’s Wireless Serial App uses over 2000 lines of code when you count all the libraries it depends on, and it only takes about 8.2 kB, so I wonder why your application would take up so much more space.

In case you have not done so already, I recommend looking at the .map file generated by SDCC so that you can see how much space each function is taking. This might give you an idea of which areas to optimize further. If you are using pointers, you might consider adding the XDATA qualifier to them to avoid using SDCC’s 3-byte generic pointers, which have more overhead than necessary.

If that does not help, you can free up an extra 3 kB by getting a CC2511F32 programmer and overwriting the Wixel’s USB bootloader. Note that you would have to remove the code in fixed.s that refers to data structures in the bootloader (such as the USB serial number), and provide your own versions of any needed data structures.

I am not aware of any chips like the CC2511 with more flash space. You might consider getting the CC2500 transceiver, which is compatible with the CC2511, and controlling it with a separate microcontroller that has more flash space.



Thanks for the advice David.

I’m looking at the .map file in Notepad but not sure how to interpret it. Anything you can advise from this (link here)? Granted this could just be a case that the ROM is consumed, the 2000 lines in my app excludes the libraries called.

I use pointers quite a bit for passing arrays between functions, so will try the XDATA qualifier.

I will look into the other points you mention too.

Many thanks.


If you scroll down far enough in the .map file, you will start to see lines like this:

C:   00000500  _main                              Firmware

This tells us that the main function is at address 0x500 of code space and it was defined in Firmware.c. If you scroll down further, you can see that the next function in code space is frequentTasks, which starts at address 0x5C4. So this tells us that main takes up about 0xC4 bytes, which is 196 in decimal.

The .map file is cluttered with lots of symbols generated by the compiler for its own internal use. The symbols whose names start with an underscore are the most interesting ones because each one generally corresponds to a function or variable that is defined in the C source code. If you have the software utility grep, you can run this command to print out all the symbols defined in code space whose names start with an underscore:

grep -E "^C: +\w+ +_" Firmware_GEN6dev.map

It looks like the functions defined in Firmware.c go from 0x400 to 0x403C, so they take about 0x3C3C bytes (15kB). The function processUserCommand takes 2913 bytes.