I use MPLAB X (sometime MPLAB 8) and i get some project to finish. I have these HEX files:
bootloader.hex
magic_flag.hex
Bootloader is loaded from address 0x0 to 0x7FF. The magic flag has position in address 0x40 (so in bootloader area).
And now I need setup the project in MPLAB X to load everything (bootloader+magicFlag+app).
It is possible to load bootloader, and then magicFlag and then setup Preserved flash memory and work on the application and load only appl area (from 0x800 to 0xFFFF) but it's not much comfortable for me. For example, when I worked with Freescale with WinIDEA IDE from iSYSTEM, I was able to set many SX files to load, very simple, quickly and it was working. But when I try it with MPLAB X I always get error:
(944) data conflict at address 0h between appl.hex and bootloader.hex.
What I tried:
setup files for loading in Project properties (section Loading)
setup memory range in project properties (section ICD 3)
But I thing that it is not problem with ICD 3 loading. Because the error came in time when the MPLAB X is creating unified hex file.
And for imagine, this is my part of linker:
CODEPAGE NAME=BootResetVec START=0x000 END=0x007 PROTECTED
CODEPAGE NAME=BootHighISR START=0x008 END=0x017 PROTECTED
CODEPAGE NAME=BootLowISR START=0x018 END=0x029 PROTECTED
CODEPAGE NAME=TRMAGIC START=0x040 END=0x07F PROTECTED
CODEPAGE NAME=BootLoader START=0x080 END=0x07FF PROTECTED
CODEPAGE NAME=page START=0x800 END=0x7D7F
CODEPAGE NAME=debug START=0x7D80 END=0x7FFF PROTECTED
I reminder, that this is not only my project and a just have bootloader with magicFlag and I have only source code from the appl. Of course, it will be better to have bootloader source code with appl in one project.
So, the MPLAB X is killing me, please help me :-)
You can't load two application to the same memory address space!
You need to recompile magic_flag application to higher address than you can merge the both in program FLASH memory. Linker can't do it instead you. :)
Related
I am making a USB Bootloader for PIC24FJ128GC006 and I am going to map part of the flash memory for the Bootloader and the Application code.
I added the linker script from Microchip MLA v2015_08 usb device bootloader to my PIC24FJ code file.
In the linker file, the __BOOTLOADER must be defined in order to access the 0x400 address region.
#ifdef __BOOTLOADER
program (xr) : ORIGIN = 0x400, LENGTH = 0x35BE
#else
program (xr) : ORIGIN = 0x4002, LENGTH = 0x117F4
#endif
In the main.c of my bootloader code, I have already #define __BOOTLOADER, but when I program the bootloader code to the PIC using ICD3 and check the program memory by using the PIC Memory Views of MPLAB Window Toolbar, the data is written to the 0x4002 address and not in the 0x400.
What can be the problem?
Okay. I have solved my problem above. You should write #define __BOOTLOADER in the linker file, not in main.c.
Another problem has risen though. In my code file dashboard, it indicates there that I have used 97% of the program memory after defining the __BOOTLOADER. So my question is that, can I remove some codes in the linker file to decrease the used program memory? If yes, how can I know what to remove in the vector tables?
Currently i am trying to get the STM32F405 to jump to bootloader from application code without the use of the boot0 and boot1 pins.
I did already try multiple things to get that done but it always ended with the the firmware jumping to the bootloader (at least it seems like it) and after approximate 18 seconds the firmware restarts (no Watchdog or similar things that could wake the chip up again are used as far as i know).
During those 18 seconds if i try to update the firmware the bootloader doesn't get found.
I tested things like:
1. (STM32F4 Jump to Bootloader via SoftReset and without BOOT0 and BOOT1 Pin)
Set a value in SRAM
Restart the STM32F405 with NVIC_SystemReset() to get the STM32F405 to close reset condition
Check for value in SRAM ( if it's set do the following )
Move stackpointer to bootloader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
2.
During runtime call function JumpToBootloader()
Within that function disable interupts, reset SysTick, reset SYSCLK, call RCC_DeInit()
Move stackpointer to bootlader address
Jump to bootloader address + 4 (0x1FFF0000 + 4)
One approach i found but couldn't test yet was to do basically what i discribed in try 1. but using assembler code within the STM32F4xx startup file.
The problem here is that the tutorial i found uses the KEIL assembler syntax which i cant use because i use the Atollic TrueSTUDIO and i have not enough knowlege about assembler to change the KEIL syntax to standard assembler syntax.
The thing that confuses me the most is that in an other project i use an STM32F3xx (cant remeber the correct number) and i do basically the same thing as in try 2. but with the the bootloader address of the STM32F3xx (0x1FFFD800) and it works perfectly fine and i can update the firmware via USB.
So the questions i have:
What could i try next to get the bootloader running?
What could be the cause in my current situation for the firmware to restart after X seconds?
A few days ago i found the cause of the problem i had.
Within the "system_stm32f4xx.c" the I2S clock got configurated and in my project that clocks doesnt get used.
Im not 100% sure why, but after removing this block of code everything works perfectly fine.
(sorry for late answer, kind of forgot about the post :D)
I have an application compiled using GCC for an STM32F407 ARM processor. The linker stores it in Flash, but is executed in RAM. A small bootstrap program copies the application from Flash to RAM and then branches to the application's ResetHandler.
memcpy(appRamStart, appFlashStart, appRamSize);
// run the application
__asm volatile (
"ldr r1, =_app_ram_start\n\t" // load a pointer to the application's vectors
"add r1, #4\n\t" // increment vector pointer to the second entry (ResetHandler pointer)
"ldr r2, [r1, #0x0]\n\t" // load the ResetHandler address via the vector pointer
// bit[0] must be 1 for THUMB instructions otherwise a bus error will occur.
"bx r2" // jump to the ResetHandler - does not return from here
);
This all works ok, except when I try to debug the application from RAM (using GDB from Eclipse) the disassembly is incorrect. The curious thing is the debugger gets the source code correct, and will accept and halt on breakpoints that I have set. I can single step the source code lines. However, when I single step the assembly instructions, they make no sense at all. It also contains numerous undefined instructions. I'm assuming it is some kind of alignment problem, but it all looks correct to me. Any suggestions?
It is possible that GDB relies on symbol table to check instruction set mode which can be Thumb(2)/ARM. When you move code to RAM it probably can't find this information and opts back to ARM mode.
You can use set arm force-mode thumb in gdb to force Thumb mode instruction.
As a side note, if you get illegal instruction when you debugging an ARM binary this is generally the problem if it is not complete nonsense like trying to disassembly data parts.
I personally find it strange that tools doesn't try a heuristic approach when disassembling ARM binaries. In case of auto it shouldn't be hard to try both modes and do an error count to decide which mode to use as a last resort.
A hex file is provided to the Microchip IPE programming tool and an ICD3 for a PIC 32F. The hex file includes an out-of-memory-map data location with a config bit set that sets a configuration register so tha the contents of ROM cannot be read withut erasing the chip.
When Using Microchips IPE tool, will an ICD 3 actually verify the PIC 32F chip and then secure it, or will it simply program the chip blindly in one step since the chip cannot be read back.
It will actually verify the chip, but it will program it bindly, believing that the hex is intended for that part.
The IPE checks for the appropriate part to set the fuses (config words). If it is on a different location than the assembled hex, you may run into problems like, for example, having a WDT running. So, if the hex was assembled for another part, it will work just the same.
Here is my question,
I work on an application embeded in a board we manufactured ourselves for a space project.
The board uses a LEON2 Processor which is a derivate of SPARC v8 and we also use RTEMS as OS.
In this application we have to save default value for various tables for the FS in the EEPROM, so the user can modify them how he wants without having to do it everytime.
To achieve this I simply created a new section (.eeprom_data) and I placed it at address 0x6007cc40 which is in the EEPROM. It was done by using a specs file and a custom linker script which located the section at the correct address and told the compiler to put certain variables in this same section.
It seems to be working fine in this regard.
Here is an extract of objdump for the section and one particular var:
6 .eeprom_data 000033c0 6007cc40 6007cc40 00038a80 2**3
CONTENTS, ALLOC, LOAD, DATA
6007fbda g O .eeprom_data 00000002 Downlink_Priority_Vc1_default_value
The only problem is that it seems not to be fully working. My application runs correctly with no problem but doing a simple test like this only partially work:
Eeprom_ChipEnable(TRUE);
managed_faulty_sectors_default_crc = 0x789A;
tmp = managed_faulty_sectors_default_crc;
Eeprom_ChipEnable(FALSE);
The write operation which should write 0x789A in EEPROM does absolutely nothing
The read operation however works perfectly and returns correctly the data that is stored in the memory.
I don't really know how to solve this problem so I hope someone can give me a hand.
Thanks, Léo.
Thanks for your answers.
For some reason, when the HW engineer designed our board they did not allow the addressing of single 16 bits address only 32 bits address..
Are you sure the data cache (if any) is flushed before you disable the EEPROM?
And, are the EEPROM variables properly declared volatile?
Do you compile with optimization flags ?
I'd guess the compiler to optimize away the write unless managed_faulty_sectors_default_crc is declared volatile .
Also how is managed_faulty_sectors_default_crc mapped to the .eeprom_data section - does objdump give any clue as to wether they're mapped correctly ?