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.
Saturday, November 30, 2013
Friday, November 29, 2013
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.
Thursday, November 28, 2013
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))
XC16 has the following attribute for this:
__attribute__((user_init))
Wednesday, November 27, 2013
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.
Thursday, November 21, 2013
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.
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.
Wednesday, November 20, 2013
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!
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!
Tuesday, November 19, 2013
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.
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.
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
Subscribe to:
Posts (Atom)