1
\$\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.

In the bootloader code there is the following code:

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

I suspecting that the firmware application is interfering in the part of the instruction space that the bootloader occupies. I did nothing in the XC8 application to ensure it does not overlap the bootloader already present in the device, I just compiled it and use the .hex file to be uploaded.

At this moment, my firmware application does not need to invoke the bootloader and does not need to use any I/O resources that are also used by the bootloader.

I tried to modify linker comands, in a .map file, but I don't know if this is the way. I didn't put it here because it is too extensive

Does someone know, or has a tip, of how to configure MPLABX, or write in the application's firmware, to guarantee it does not overlap ?

Following are two images of the configuration project that MPLABX provides. Remembering this is the project of the application firmware.

enter image description here

enter image description here

Improve this question
\$\endgroup\$
5
  • 2
    \$\begingroup\$ The .map file is not an input into the linker to tell it where to put stuff. It's an output from the linker to tell you where it put stuff. \$\endgroup\$ – brhans Jun 19 '19 at 16:42
  • \$\begingroup\$ @brhans, thanks. But, do you know how I can to tell it where to put stuff ? \$\endgroup\$ – Daniel Jun 19 '19 at 16:53
  • \$\begingroup\$ @Daniel I haven't had time yet to actually read and then engage what you wrote. I have a little time to dash something off, though. In general, a bootloader sits somewhere -- sometimes in a place that can be written onto, sometimes not. Regardless, each compiler has its own and often incompatible "program model" it uses. The output they generate often fits a shared or common format that can be used to properly load it into memory. But in no way does this mean that they use the same program model nor map code/init data to the same places. The map file tells you where they actually placed stuff. \$\endgroup\$ – jonk Jun 19 '19 at 19:39
  • \$\begingroup\$ @Daniel When I have problems similar to what I think you are having, I look immediately at two things. (1) I study the bootloader docs to find out exactly where it is located, what it protects and what it does not protect, and in general try and get a handle on the bootloader itself. (2) I study the generated map files for both compilers, CAREFULLY. I will usually use compiler options designed to MAXIMIZE the information produced in such a file, too. I almost ALWAYS find the problem this way. Be sure to look at where/how the stack is handled, too. \$\endgroup\$ – jonk Jun 19 '19 at 19:41
  • \$\begingroup\$ @Daniel The final place I go, should I find the problem and need to fix something, is the linker input file specifications. Often, there is something you can do/adjust to force the linker to place things where the bootloader can successfully handle them. I don't know if the same linker is used in both your cases, or not. If two different linkers, then you may have two documents to study. \$\endgroup\$ – jonk Jun 19 '19 at 19:43

Your Answer

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

Browse other questions tagged or ask your own question.