0
\$\begingroup\$

I have a bootloader to PIC18F4550 that was written using Mikro C for PIC and I have two firmware applications, one was written using Mikro C for PIC and the other using MPLAB X with XC8 compiler.

With the bootloader installed, I can upload the application written in Mikro C without problem, but, with the same bootloader installed, when I try to upload the application written in MPLABX I can't. I load untill 100% but in the end it crashes . I thought that upload the applicatoin in hex it would not be a problem and would be independant of the tool used.

The version of the bootloader that I'm using is this that I found in this site:

http://microcontrolandos.blogspot.com/2013/09/pic-bootloader-usb.html

Some one has any idea of why it is happening ?

EDITED:

I don't know if it is at the top or at the bottom of memory. Based on the following code, I guess it is on the bottom:

const unsigned long BOOTLOADER_SIZE = 8000;//7432;
const unsigned long BOOTLOADER_START = (( __FLASH_SIZE - BOOTLOADER_SIZE) / _FLASH_ERASE) * _FLASH_ERASE;

This says, basically, that the start of bootloader begins at memory region given by the flash memory size minus the bootloader size. So, I don't know why, it divided and multiplied by the size of flash erase block. The size of the bootloader is already given too.

I did nothing to the XC8 app to ensure it does not overlap, I just compiled it. How can I do ensure it does not overlap ?

|improve this question
\$\endgroup\$
  • 2
    \$\begingroup\$ The issue is not the tools, but in incompatible expectations of the two programs (in their ultimate compiled and linked forms) Since you provide no details of the intended bootloader/application handoff, this is unanswerable. Consider things like link address, entry point, and system state. \$\endgroup\$ – Chris Stratton Jun 14 at 13:42
  • 1
    \$\begingroup\$ Do both sets of tools use the same linker script (or equivalent) format? If not I would make sure that they both are specifying the same entry point and range of flash memory for the program. \$\endgroup\$ – user4574 Jun 14 at 15:27
  • 1
    \$\begingroup\$ Another thing to mention is that the XC8 linker has some bugs related to accessing constants in memory on certain devices. There are liker options like +NVMREG that correct these. Its worth checking if need to set any of these options. \$\endgroup\$ – user4574 Jun 14 at 15:40
  • \$\begingroup\$ @user4574 I confess that I don't know if the tools use the same linker script. Do you know how can I do it ? \$\endgroup\$ – Daniel Jun 17 at 12:57
5
\$\begingroup\$

You're right — in principle, the bootloader shouldn't care what tools are used to create the application code. As far as it is concerned, the application is just "a bag of bits".

However, the presence of the bootloader puts constraints on the application:

  • The application cannot clobber the part of the instruction space that the bootloader occupies.
  • The application must be startable at an address known to the bootloader.
  • If the application needs to be able to invoke the bootloader, then it needs to know how to do that.
  • If the application needs to use any I/O resources that are also used by the bootloader, then any conflicts need to be resolved through "rules of engagement".

It's possible that not all application development environments are completely compatible with the specific requirements of your bootloader.

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ At this moment, my application does not need to invoke bootloader and does not need to use any I/O resources that are also used by bootloader. However, I would like to know. 1) How can I verify if the firmware application is not interfering in the part of the instruction space that the bootloader occupies ? 2) How can I know that the application is starting at a known address to the bootloader? Do I need to do it writting code in the application or can I do it only configuring the MPLAB X tool ? \$\endgroup\$ – Daniel Jun 17 at 12:48
  • 1
    \$\begingroup\$ The PIC18, boot vector is always at address 0x0000. Normally the linker will always place a jump instruction at address 0x0000 that goes to the C startup code. When using a boot loader you can shift the user-application to a different address using the --CODEOFFSET linker option. For example --CODEOFFSET=1000 moves boot vector of the user appliation to address 0x1000. All the details of how to place data at specific addresses is in the XC8 Compiler User's Guide. See section 3.5.3. ww1.microchip.com/downloads/en/devicedoc/50002053g.pdf \$\endgroup\$ – user4574 Jun 17 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.