Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
integration in user application problem [solved]
I would like to integrate DS30 with a very simple test application (led blinking) in the some project.
I use mplab/C30 with a dspic33fj256m710.
I have a problem with the the modification the goto to the user data initialisation :
; ---------------------------------
; Start of code section in program memory
; ---------------------------------
  .section *, code,address(STARTADDR-4)
usrapp: goto __resetPRI

I get with the linker : undefined reference to `_resetPRI'
I try to declare : .extern __resetPRI in ds30loader.s
I try with 1,2 or 3 underscore '_' !
I try with and without include the file crt0.s in the compilation.

If somebody have a idea for me or a exemple ?
thanks for your help

I maybe find a solution :
If I remove the crt0.s, and replace it by crt0.o -I dont find same version as firmware manual) I find mind in /MPLAB C32 Suite/pic32mx/lib, I don't know if it's the same file.
Now I have no link error.
But my main code (blinking led C application) is place in the flash after the bootloader... ?
I have to use placement code directive in my main.c ???

thanks for your idea
Microchip seems to have hidden the crt files inside some other file.
I don't know how to do integration now.

Obviously you shouldn't use a PIC32 file for dsPIC33 project.

There's an alternative to _resetPRI in the manual.

I have made some tests and read the C30 manual.
The firmware manual is updated accordingly:
Many Thanks for yours tests.
With your solution (goto directly in the main), will we have problems with stack initialization and data initalization in our application software ?
The stack should be initialized just fine.
But data won't be initialized.
I am working through some of the same minor issues while integrating the ds30 bootloader into my dsPIC33 project.

I had some issues with clock speed and baud rate, so for debugging purposes, I built a little test loop to generate some serial output:

.equ TESTCHAR, 'A'
testloop: SendL TESTCHAR /*endless loop to test UART output*/
goto testloop

Now I ask the question: Why not just use the bootloader as a standalone project, and then load the application? What are the reasons to integrate the bootloader into a project? I am wondering what the pros and cons of integration are?

I find the combined assembly and C code a big hassle, especially sharing constants and variables.

BTW the bootloader works great and I really appreciate the effort put into the development and support.

Thank you for the feedback!
As far as I see it, there is no reason the integrate them.
I most cases it might even be nearly impossible the achieve.

The only reason I can think of is if you want to send a hex file
to Microchip for them to burn to the chips you buy. But you can
combine them at that point in time as a separate activity without a combined MPLAB project.
I will release a tool that combines 2 hex files(boot loader + application).

Next time, start a separate thread.
A tool to combine the two hex files would be most excellent!
(2011-02-15, 00:09:03)Mikael Gustavsson Wrote: I will release a tool that combines 2 hex files(boot loader + application).

Did you finalize any tool to combine the boot loader + application.
It would be very helpful to have that kind of tool.

My tests seem to work correctly with the application.hex file, with or without using the bootloader... Excatly like I want...
But programming the PIC from scratch require two steps. First programming the device with bootloader using pickit3, and then update the PIC with the the application through the bootloader.
It would be perfect and reduce this into just the first step only, if the device would be used in a big production.
See, Products-Utilities-ds32 HEX Merger
Is it possible to download, or what is the cost of it?

Forum Jump:

Users browsing this thread: 1 Guest(s)