open source dsPIC bootloader + GUI

Hi
 
My company has decided to share the source code of the dsPIC bootloader that until now was used internally in some of our projects. I think this software could be useful for someone. For that reason I decided to publish it here.
 
The bootloader consists on:

• an open source firmware code, written in assembler (generic for all dsPIC),
  
• a Windows based Graphical User Interface (comes with user's guide, algorithm flow, etc.)

The main features of the firmware are:

• Auto-Baud rate detection (allowing clock independency)
  
• Possibility to Read/Write Program Memory
  
• Possibility to Read/Write EEPROM Memory
  
• Possibility to Read/Write Configuration registers

You can easily add new dsPIC devices (by default comes only with dsPIC30F4011 and dsPIC30F3011), define and protect memory zones through a XML configuration file.
 
You can download both the firmware and the GUI at:
 
http://www.ingenia-cat.com/index.php?lang=en
 
Enjoy it

Thank you very much, Albert.

Bootloaders have been a hot topic on the forums for several months.I'm sure that many of us appreciate your company's contribution to the community.

The assembly code looks tight and well crafted. I'm looking forward to trying out the host application and GUI.

Cheers!

Albert Torne,
           Thank you very much to u and ur company.Today only i was looking for it. can you tell me can i use this for dsPIC33F series.
anyways i guess this will be guideline to develope it for my dsPIC33F. I have to write it in 'C'.I will do it very soon and  make it available for all.

vihang

I guess that the firmware is compatible for both dspic30 and 33 series.
 
Regarding the GUI, the only thing you should do is to add your new device in the dspic configuration file. This is well explained in chapter 2.2.4.1 of the user's guide
 
You don't have to write anything ;)
 
Rgds

Hi,

Firstly, thank you for the free bootloader - I have been putting this off for a while now and this was just too good an opportunity to pass up.

I have managed to edit the xml file as far as the memory addresses are concerned (need to support dsPIC30F5011) but I am having a hard time finding the DEVID for this device.  Does anyone know where I can find a list from Microchip of the DEVID for the various devices.  I have checked the datasheet and can't find it anywhere.  I know it is located at memory location oxFF0000, but what the actual value is I can't find.

I see from the xml file that the DEVID for the dsPIC30F4011 = 0x0101 and dPIC30F3011 = 0x01C1, but this didn't help me to figure it out.  Maybe I have overlooked something obvious?  Any help will be appreciated.

Thanks

The document we use is:
 
dspic30F Flash Programming Specification
 
In section 10.0 you will find all dspic30F devid's
 
Rgds

Thanks Albert for your prompt reply.

I have added the dsPIC30F5011 to the xml file (attached), but when I try to connect to the device using the bootloader application I receive the following message:

dsPIC identification failed
error code: -5

Did I make a mistake in my edit of the xml file?  Is there anything else that I can check to correct this?  I have already programmed the device with other code to verify the DEVID and I readback the value as expected (0x0080).

I also changed the bootloader config to use the internal FRC timer - is this acceptable or could it be the cause of my problem?
config __FOSC, CSW_FSCM_OFF & FRC_PLL16

Best Regards,
Donovan

Attachment(s)

ibl_dspiclist.xml.txt (1.27 KB) - downloaded 823 times

The xml file looks good.
 
We have not tested the bootloader with the internal oscillator. At first sight, I see two differences when using the internal FRC:
 
1- The internal oscillator is far less stable than an external clock. This may lead to transmission errors.
 
2- The internal oscillator (with PLL = x16) will decrease the delays by a factor of 7.37/7.5
 
I don't know if these differences may cause the bootloader to fail. I'll forward the problem to our technicians in order to test this configuration.
 
Rgds,
Albert

Donovan, just a question: 
 
the firmware we provide uses the alternate UART1, and 5011 has no alternate UARTs. Have you modified the firmware to use your UART1 or UART2 instead of AlternateUART1?
 
Rgds

After experimenting further I did manage to get it to connect and re-program using the FRC without PLL.  My particular design uses the FRC to startup and then switches over to a 10MHz external  so I needed the bootloader to work with the FRC - which it does!
config __FOSC, CSW_FSCM_ON & FRC & EC_PLL8

Something that I saw in the bootloader code that also needed changing was the start address for my device (dsPIC30F5011) to be the same as the xml file
.equ START_ADDRESS, 0xAD00                ; Relative to 0x0100

Regards,
Donovan

Albert, I used the UART1 by making the change suggested in the accompanying documentation

Programming the configuration has been somewhat problematic, but I suspect that this is because I am running the device at 3V3 instead of 5V.  I have even experienced problems when trying to erase the device using the ICD2 because of using 3V3.  Power the chip from 5V and it works 1st time! Unfortunately, this is not practical for my final design ...

Configuration Memory locations F80006 (RES1,RES2,RES3) and F80008 (RES1,RES2,RES3) seem to be corrupted (programmed to 0x00) and this causes the device not to be able to be erased or programmed properly.  I didn't think that these registers were writable in the first place?  Any ideas here?


Best Regards,
Donovan

Hi Donovan,
 
How do you check the content of the RESERVED1 (0xF80006) and RESERVED2 (0xF80008) configuration registers?
 
The bootloader should not modify these positions if they did not appear in the hex file.
 
Could you make a little test?
- Program the bootloader into the dsPIC using ICD2
- Check the content of the configuration registers
- Reprogram the dsPIC using the bootloader and a dummy program with the same configuration registers as the bootloader
- Check the content of the configuration registers again
 
Does the values change?
 
Regards,

Hi Roger,

I used ICD2 to read the registers by using the "read target device" function in MPLAB.  It seems that if there is an invalid value present ICD2 issues a warning, but if it is valid there is none.  I don't know how to check the actual value when it is valid.

I noticed two things when running the experiment (see attached screendump)

After programing the device with the bootloader (program code and configuration) the config registers have been set to 0x00 according to ICD2.  Also, the actual program code has not been written to the device (all program memory has been set to 0x00 also).

The only way that I can now reprogram this device is to connect 5V power to the device and use ICD2.  ICD2 cannot reprogram this device if I leave the device power at 3V3.

If I use the bootloader to reprogram only program memory (not config) everything works fine and I can reprogram it multiple times with different code correctly.

Have you ever tested the bootloader with the device running at 3V3?

Best Regards,
Donovan

Attached Image(s)

Dononan,

We did not test the bootloader at 3V3.
This behavior looks like the consequence of modifying the Code-Protection bits (GCP, GWRP of FGS). Are you protecting this zone in the XML file?

This could be the reason of reading 0x00 in all memory positions.

The only way to unset these bits is performing a bulk erase and that can only be done in Normal-Voltage Systems (>4.5v)

Hi Roger,

I think I am protecting these bits in the xml, a copy of which I attached in an earlier post.  Please let me know if there is a mistake there - quite possible.

Does the bootloader make use of "bulk erase" when programming the configuration bits?  This may explain the behaviour that I am seeing.

Here are the configuration bits that I am setting for both the bootloader code and the dummy code that I re-program onto the device:

// DUMMY CODE CONFIG
_FOSC(CSW_FSCM_ON & FRC & EC_PLL8);
_FWDT(WDT_OFF);
_FBORPOR(PBOR_ON & BORV_27 & PWRT_16 & MCLR_EN);
_FGS(CODE_PROT_OFF);

// BOOTLOADER CONFIG
config __FOSC, CSW_FSCM_ON & FRC & EC_PLL8
config __FWDT, WDT_OFF             
config __FBORPOR, PBOR_ON & BORV_27 & PWRT_16 & MCLR_EN
config __FGS, CODE_PROT_OFF        


Best Regards,
Donovan

Roger, Albert,
 
Thanks for releasing this code.  I haven't tried to use it yet, but the documentation alone is a worthwhile read. 
 
I still have a question, though, about how to compile a program so that I can use it both with an d without a bootloader (yours, or a "generic" bootloader).  In C30, is it simply a matter of telling the linker to reserve some space, and to begin your "main" routine at 0x0100?  Or, would I link in your bootloader to each program every time I compile it, and essentially "overwrite" the bootloader code with the same code each time? 
 
I asked the question here:
http://forum.microchip.com/tm.aspx?m=137095
 
... but still don't have it clear in my mind. 
 
Thanks,
Dave

Hi all,
 
Donovan your XML looks right.
The bootloader does not use "bulk erase" for two reasons; first because the configuration registers does not need to be erased before a write operation and second because a "bulk erase" would erase also the bootloader
 
Another thing, why are you reprogramming the configuration registers if both the bootloader and your code have the same values?
 
Anyway the bootloader should work also in this case, when I will have some "free" time I will try to reproduce your problem (programming at 3V3).
 
Regards,

Hi Dave,
 
What we do is the situate the bootloader at the end of the program memory and modify the XML according to that.
Then, develop your program as you do normally without the bootloader... you even do not have to specify the origin of your code (starts by default at 0x0100).
 
If you want you can also modify the linker to reserve the positions of the bootloader, but even if you do not do it the bootloader will not be overwritten cause the GUI will detect the zone as protected.
 
I hope this answer you questions.
 
Rgds,

Hi Roger,

Thanks for your reply.

You asked:

Another thing, why are you reprogramming the configuration registers if both the bootloader and your code have the same values?

I did this in response to your initial request in an earlier post:

Could you make a little test?
- Program the bootloader into the dsPIC using ICD2
- Check the content of the configuration registers
- Reprogram the dsPIC using the bootloader and a dummy program with the same configuration registers as the bootloader
- Check the content of the configuration registers again

Did I misunderstand your request?

I look forward to your results with programming at 3V3 when you get a chance.  Thanks again for the bootloader which I am now able to use and works very well for reprogramming the device program code - even at 3V3.

Best Regards,
Donovan

Hi Donovan,
 
When I read your post I forgot my previous suggestion, sorry was my mistake. [8|]
 
I don't have any dsPIC30F5011 available now because in fact we don't use it in our projects. Thus, I cannot reproduce exactly your problem.
Despite I did the test with a dsPIC30F4011 working at 3v3 and the programming of both program memory and configuration registers was succesfull.
 
I will ask for some 5011 and I will repeat the test.
 
Best Regards,
Roger