Uninitialized variable problem

GCC Provides some pretty good warning features for you, to help avoid common problems.
One of this is warning for uninitialzed variables.

Let's see the following code:

 typedef union  
 {  
   uint8_t value1;  
   uint8_t value2;  
 } demostruct;  
 .  
 .  
 .  
 demostruct uninited;  
 int i;  
 for (i = 0; i < uninited.value1; i++)  
 {  
      //do something  
 }  

You'll probably be in some serious trouble running this code, as whatever you do in the for loop, the execution of it surely won't be as you imagined.

Mplab X linker script modification

Besides all the hassle that comes with Microchips IDE, I found one thing, which is pretty neat.
You can easily modify your linker script.

Or per se, use an external linker script.

How do you do it?
Read on.

Mplab X code download

Mplab X has 2 options to download your code.

The one which runs standalone, and the one that you debug.

Remember?

Seems to me idiotic, that you can't assign a build configuration to either one of them.

Initialization before main

Let's say you have some peripheral, that you want to be up and running in your code, before you enter your main() function.

XC16 has the following attribute for this:

__attribute__((user_init))

Remove unused code madness

So, Bootloader seems to work properly. Only one thing left to go. Let's try this sucker at max optimization for size. Since nobody once to have a waste of expensive flash memory.

Debug executive madness, Updated!

I mentioned that there are 2 possible ways to download your code, one which is able to run on its own, and one that is used for debugging. You can read more about it here: Debug Executive

Now that I'm able to read the programmed code from my dsPIC, let's see what the debug executive looks like. So I downloaded my blinky once pressing the green, and once pressing the red button.

Read the program from a dsPIC

So I've got the bootloader running on the dsPIC, it looks as if it works, but does it really work?
To really be sure that the user blinky code got downloaded correctly to the dsPIC, I'd like to do some verification between the hex which should be downloaded and the dsPIC's program flash. You'd think this would be easy: Wrong!

Debugging a bootloader code

I am currently working on a bootloader for a dsPIC33FJ.

If you develop a bootloader, you might want to test it during its development. What better is there to see if a code is running, then a blinky? The blinky in the previous post is also the testing blinky for the bootloader.

The quirks of downloading code to dsPIC

I wanted to see how my compiled program runs on my dsPIC33FJ. Never did I imagine this was going to be so hard.

Usually you write your blinky code, you download it via your IDE to your uC, and then you lean back and watch the blinky code do its magic on the LED.

Turns out the dsPICs do not have a hardware to support direct debugging, therefore you can compile 2 different codes.

• Debug code:
• Debugable
• Does not run standalone
• Standalone code:
• you download it, it runs, that's it